[Grace-core] Modules and Visibility

[Andrew P. Black]

I've been doing some reading, amazing as that sounds.

I read Kim's module proposal, but maybe missed some of the details.    I was trying to ignore syntax and figure out what it was actually bring ing to the language.

There seems to be three things:

	(1) some kind of public/private/protected qualifiers on methods
	(2) separation of interface from implementation
	(3) logical nesting without physical nesting, so that I can bring a set of declaration into my scope without having to write them there,
	(4) "separate compilation", and rules about files. 

(1) is important, but still don't see the mechanism that will make this happen.  More on that later.   
(2) seems unnecessary, since we have already separated types from classes, which provides exactly this distinction.
(3) seems like a practical necessity, but is primarily a syntactic matter, and
(4) seems like stuff that should not be in the language definition at all, sine most novices will be using an IDE rather than files.


For (3), I am tempted to suggest a notation a bit like that of Fortress, but modified for our syntax:

	import * from modA



brings all of the names defined in modA into scope.
(Fortress would write import modA.{...}, but we are using braces and ... for other things.)

	import k, l, m, n from modA

brings in just k, l, m and n.   (Fortress would write import modA.{k, l, m, n})

How should the things thus imported be referred to?  That is, do the imported names need to be qualified?  I think that k, l, m and n should be usable without qualification, since they were explicitly imported, whereas * will introduce qualified names.  That is, with the import * form one would have to write modA.k, modA.l, etc.   The motivation for this rule is that one should always be able to see what names are in scope, without having to go and look at some other module or its documentation. Can we unambiguously use '.' for this purpose as well as for method request?  Does this still work if we adopt James suggestion make modules objects?   Maybe it's too early to decide that.

(1) seems to be the most important technical issue.  Having a method accessible only to an object itself and its inheritors (Java "protected" = Ruby's "private") is easily accomplished by the syntactic restriction that certain methods may be requested from "self" but not from anyone else.   I live using method names prefixed with _ for this purpose, because then the restriction can be enforced by a simple static check, rather than a dynamic check, but I don't feel strongly about it.   I can't think of a good name for this form of access restriction: maybe "confidential" or "descendants only"?

The distinction between "private" in the Java sense and "public" is more difficult.  Private really means lexically (=statically) bound, while public really means dynamically (= late) bound.   These modifiers thus change the dynamic semantics of the language, and should not be used lightly.  Moreover, having the definer of an object decide to make something static pre-supposes omniscience: the definer has to know who will be extending the object to know whether a method x, not part of the client interface, should be private (and thus unavailable to extenders to re-define) or confidential (available to extenders to use as a hook method if they need it).

So  I was pleased to come across User-Changeable Visibility: Resolving Unanticipated ... , which puts that decision into the hands of the extender.  The definer of an object can decide on a default visibility, but extenders can change that decision at composition time.  


@inproceedings{ducass2007,
	Address = {New York, NY, USA},
	Author = {Ducasse, St\'{e}phane and Wuyts, Roel and Bergel, Alexandre and Nierstrasz, Oscar},
	Booktitle = {Proceedings of the 22nd annual ACM SIGPLAN conference on Object-oriented programming systems and applications},
	Doi = {10.1145/1297027.1297040},
	Isbn = {978-1-59593-786-5},
	Keywords = {traits protected public private},
	Location = {Montreal, Quebec, Canada},
	Pages = {171--190},
	Posted-At = {2010-12-14 09:33:22},
	Priority = {3},
	Publisher = {ACM},
	Series = {OOPSLA '07},
	Title = {User-changeable visibility: resolving unanticipated name clashes in traits},
	Url = {http://dx.doi.org/10.1145/1297027.1297040},
	Year = {2007},
	Abstract = {A trait is a unit of behaviour that can be composed with other traits and used by classes. Traits offer an alternative to multiple inheritance. Conflict resolution of traits, while flexible, does not completely handle accidental method name conflicts: if a trait with method m is composed with another trait defining a different method m then resolving the conflict may prove delicate or infeasible in cases where both versions of m are still needed. In this paper we present freezeable traits, which provide an expressive composition mechanism to support unanticipated method composition conflicts. Our solution introduces private trait methods and lets the class composer change method visibility at composition time (from public to private and vice versa). Moreover two class composers may use different composition policies for the same trait, something which is not possible in mainstream languages. This approach respects the two main design principles of traits: the class composer is empowered and traits can be flattened away. We present an implementation of freezable traits in Smalltalk. As a side-effect of this implementation we introduced private (early-bound and invisible) methods to Smalltalk by distinguishing object-sends from self-sends. Our implementation uses compile-time bytecode manipulation and, as such, introduces no run-time penalties.}
}

What I like about this paper is that it clearly explains that private means lexically bound, and that normal public methods are dynamically bound.  It thus meshes well with Grace's "one true message send" rule.  If it's private, there is no message that can be sent, by anyone, at any time.   The paper allows this to be changed on trait composition, and we don't have traits, but I believe that the same thing could be done for object extension.

	Andrew



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailhost.cecs.pdx.edu/mailman/private/grace-core/attachments/20111114/37993ca6/attachment.html>