[Grace-core] More thoughts on modules

[Kim Bruce]

On Jun 12, 2011, at 9:31 PM, Andrew P. Black wrote:

> 
> 
> 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 ?

I'm not sure we need variables, as we can always encapsulate them in constant objects with getters and setters.

> 
> 	"top level" methods aka procedures ?

I suspect it would be nice to have procedures / functions at the top level, but again they can be put inside objects to be exported.
> 
> 	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.

I agree, let's leave off open classes.  Writing subclasses should be fine.
> 
> 
>> 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

Ok, I must admit that this was a shocker to me.  I think it will be a deal-breaker for many people if it is not available, at least on the typed side.  A large number of instructors (including me) consider teaching (enforceable) abstraction as key.  One of the many reasons that I have never considered teaching with Python was the lack of support for information hiding.

Looking up information on information hiding and dynamically typed languages, I found that Ruby has an interesting variant of information hiding.  If you declare a method to be "private" then it means (unlike Java and C++) that the method cannot be called with a receiver.  I.e., it can only be accessed through self.  This leaves it accessible in other methods of the class and in all subclasses, but does not allow it to be accessed even in a parameter of the same type.  This seems eminently sensible to me and does not require types in order to make sense.
(Here is an on-line reference: http://lylejohnson.name/blog/2003/12/09/private-methods-in-c-and-ruby/)

Realizing that this does not provide everything that was in your OOPSLA paper, it seems like it is a nice first step toward providing support for information hiding.  Is there any reason not to go with something simple like this?

Kim

P.S. I prefer to distinguish encapsulation from information hiding, though my definitions may not be the most popular ones.  For me, putting instance variables and methods together in a class is an example of encapsulation -- essentially putting them in one "package".  Information hiding is the notion of limiting access to features -- usually those already encapsulated in some way.  I find it useful to have different words for these two.  Can we agree on a terminology that separates these two notions?

> 
> 
>> 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
>