[Grace-core] More thoughts on modules

[Kim Bruce]

A proposal for simpler modules and accessibility protections for methods in objects and classes.

On Jun 9, 2011, at 3:48 AM, James Noble wrote:

> ...
> well it's up to us to decide
> - what problems we want modules to solve
> - how they solve 'em
> 
> for me, its composing whole programs out of various bits that seems the most important, 
> name management very much related to that.
> Also support separate typechecking / compliation, being units of deployment
> (we can just give out source code - works for JavaScript :-)
> 
> encapsulation also seems important, but I'm not sure how that goes together.
> 
>> I agree that namespaces and deployment are the highest priorities for a novice language.
> 

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.

Interface module DMod { EMod: EInterface ->   // provides any imports needed in interface

	type T { mi(Ti) -> Ui }

       const o : V

}

Implementation module implements DMod { FMod: FInterface ->  // might be the same as interface imports, but not necessarily
       object o1 {...}
       class c1 {...}
       ...
}

Only those types and objects listed in the interface module can be imported by other modules.  [I don't see any issues with an implementation module implementing several interface modules.  Does anyone?]

We do now have to face the issue of specifying which methods of an object/class are accessible to whom.  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.