[Grace-core] modules

[Andrew P. Black]

On 19 Jun 2012, at 14:29 , Kim Bruce wrote:

> Andrew,
> 
> We discussed our approaches to modularity briefly in SF.  A question:  With your implementation essentially using forwarding objects, could it be set up so that objects originating in the same module, but now in a different module could see more of each other?
> 
> The simplest example is a Set class supporting public (to the world) methods:
> 
> intersect(other:Set) -> Void
> union(other:Set) -> Void

I'll assume, given the names, that these actually return Sets, not None.

> but whose representation is as an ordered list, and with a method iterateInOrder which is only visible in the module.  The method iterateInOrder would be used to get an efficient implementation of intersect and union.
> 
> Now suppose set1 and set2 are constructed outside the module (say using exported constructors from this class).  Is there a way to set things up so that they execute the efficient implementation of intersection and union, yet the iterateInOrder method is not globally available?  How does that work with your implementation?
> 
> Thanks,
> 
> Kim
> 
> P.S.  That's the kind of thing that my statically-typed module system was designed to allow. I'm hoping your implementation will support it as well.

I don't think that this is an implementation question — I think that it's a philosophical question.  Either iterateInOrder is part of the Set interface, or it's not.  If it is, then every implementation of Set has to support it, regardless of the implementation chosen.  If it isn't, then some implementations may not support it, although others might.  Since you can't know which case applies to your argument, you have to write general code.  Doing otherwise breaks Cook's autognostic rule.

In the full version of Encapsulation polices — and I encourage us all (including me!) to read the paper, since it contains some very good discussion of the problem, even if we come to a different solution for Grace — you can have different encapsulation policies associated with different references to the same object.  This allows an objet to export a reference that gives access to a restricted interface.  But I don't believe that there is a way to "unrestrict" the interface of a reference once it has been created — if there were, that would rather defeat the purpose of the restriction!

I would deal with your situation using double dispatch.  In a SetAsSortedList object I would write

	method intersect(other:Set) { other.intersectWithList(self) }

	method intersectWithListSet(other: SetAsSortedList) { self.elementsAsList.listIntersect(other.elementsAsList) }

Of course, this means that every implementation of Set now needs to support the intersectWithListSet method, including my implementation using HashTables and James' implementation using trees, but fortunately, these objects can choose their own implementation.  So, in aHashedSet I might write

	method intersect(other:Set) { self.select { each -> other.includes(each) } }

	method intersectWithListSet(other:Set) { self.intersect(other) }

effectively ignoring the extra information about the implementation of the argument set.

	Andrew



	
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20120619/3ab778cd/attachment-0001.html>