[Grace-core] More thoughts on modules

[Andrew P. Black]

On 10 Jun 2011, at 17:02 , Kim Bruce wrote:

> A proposal for simpler modules and accessibility protections for methods in objects and classes.
>> 
> 
> 
> Since we all agree on the goals of providing namespaces and deployment, and the other options would require lots of work (and probably paper-long arguments to work out consequences), let's stick with the most simplified version of modules that provides namespaces and deployment.  Thus I am now dropping the proposal for using partial revelations.
> 
> We will provide modules mainly as a way of managing namespaces and deploying code.
> 
> Java packages and Clu clusters don't separate module interfaces from implementations (i.e, they are all in one file), while ML, Modula-2/3, Ada, etc. all separate them.  I prefer separating them as a separate interface provides a compact description of what is being exported without the clutter of what is hidden.
> 

OK!  So we have to talk about what the unit of deployment should be, in other words, what can be inside a module.

Clearly:

	Types

	constants bound to 
		objects, and thus classes

	variables ?

	"top level" methods aka procedures ?

	methods to be added to other (existing) classes (aka "open classes") ?
		I think that we don't actually need open classes now.  For example, instead of adding methods to
		String, I can import String, extend it using inheritance, and export the resulting 	
		ExtendedString class.  Someone else can import that under the name String.


> We do now have to face the issue of specifying which methods of an object/class are accessible to whom.

I think it's worse than that.   Private, as understood by Java programmers, (1) interferes with the dispatch semantics and (2) requires type information to implement it.   (Again, this is all explained in the OOPSLA paper on encapsulation.)  

The simplest thing that could possibly work would not be to have any encapsulation at all, beyond what we get from lexical scope.  Lexically-scoped procedures would give us the equivalent of (object-)private methods, and not declaring accessors for instance variables and constants would give us (object-)private data.   Otherwise, everything is public.  This may not be adequate for industrial-stength software engineering, but perhaps it is good enough for CS1 and CS2?

What do Python programmers do about encapsulation?  Clearly the lack of encapsulation has not been an impediment to having instructors use it for teaching.

	Andrew


>  I would propose that the default setting be the most restrictive, so more visibility would require an annotation.  Of course instance variables are always private (even from within the object!), but we need a way of annotating whether the derived methods (x and x:=(), if x is the variable) are visible or not.
> 
> We can stay with the traditional private/protected/public accessibility options for methods, though I'd urge us to have private be the "default" (the one you get with no annotations).  (I also wouldn't mind seeing a better name than "protected" if we can think of one.)  Making a method accessible to subclasses (protected) or all others (public) would require annotations.  
> 
> Personally, I'd leave off Java's default (package) scope for methods.  We get weird interactions when subclasses go across module boundaries and I just don't think we need it for the "programming in the medium" that our clients will be doing.  (My partial revelations provided the equivalent of package scope for methods by allowing one to hide certain method types, but the controversy over that led me to drop them.)
> 
> Like in Java, only public methods of objects could be listed in their types.  I.e., to check if on object matches (satisfies) a type, make sure it has public methods matching (at least) all those in the type.
> 
> I believe that leaves only the issue of a convenient notation inside classes for deciding how visible (the methods corresponding to) an instance variable is.  Here I am not sure where to go at the moment.  The problem is that these methods will be generated automatically and I can imagine scenarios where we might want to have different accessibility for each.  For example, if x is an instance variable declared in object o, then I could imagine wanting the generated method x() (i.e., reading x) to be public, but the method x:=(...) to be private or protected.
> 
> I suppose we could have something like
> 
> 	var x: Number <read:public, write:private> := 17
> 
> but that seems a bit clunky.  On the other hand, maybe it would discourage programmers from making the representation public :-)
> 
> Suggestions??
> 
> [By the way, I believe we still haven't figured out where and how we are going to write annotations like "private" and "protected".  Here I wrote it after the type, but I'm not strongly committed to that.]
> -------------------------------------------------------------
> This message has been scanned by Postini anti-virus software.
> 
> _______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core