[Modules] Upper case message names for accessing modules

Stephen Pair spair at advantive.com
Fri Feb 22 15:51:53 UTC 2002


Goran wrote:

> The choice of automatic altering is fine, just put a popup in 
> there perhaps based on some Preference. One note there 
> though: Stephen was talking about allowing to have implict 
> references in the code EVEN THOUGH there are multiple choices 
> (more than one neighbor module exporting the name). Thus such 
> a reference would depend on the ordering of the neighbor 
> modules (which btw Henrik has noted in the class comment of Module).

No, not if you compiled something more sophisticated than an association
into the method.  At compile time, an ambiguous reference could be
handled by prompting the user for the desired module, and suggesting
that they use an explicit reference to the name.  Unfortunately, an
implicit reference will not work when loading the module into a fresh
image (how would we know what module to bind it to?  And, we don't want
to prompt the user at load time).  Implicitly binding based on the order
of the modules would be tricky and obscure as well.

Going further with this (and this is not something that I'd suggest has
to done right this minute)...I could envision explicit binding by having
an internal name for external modules...often this would be the same as
the external module's name, but wouldn't have to be.  At load time, the
internal names for modules get bound to the actual external modules.
This could be handy if a user wanted to use a substitute for one of the
pre-requisite modules.  Sort of a module level polymorphism.  Then we
could do explicit binding and rest assured that we are not needlessly
constricting the users of the module to a certain set of imports.

I actually just encountered such a situation when trying to load the
ModuleTool...it requested version 0.0003 of the module code and wouldn't
load because I had 0.0004...even though the tool seems to work fine when
I modified the def file to require 0.0004.  It would be nice not to have
to modify modules when I want to attempt to substitute a different
module for one of the pre-reqs.  Maybe the def file could be refined to
look something like:
-----
'From Squeak3.3alpha of 30 January 2002 [latest update: #4730] on 19
February 2002 at 11:09:47 am'!

"These are the meta-prerequisites for being able to understand (i.e.
load) the definition of this module. "

 #(
		#Modules #(Squeak Language Modules 0.0003)
		#Repositories #(Squeak Language Modules Repositories
0.0003)	). !

self 
	version: nil;
	yourself.!
-----

Explicit references in ModuleTool would look like "Modules Module" or
"Repositories Repository".  A normal load of this module would attempt
to bind #Modules to #(Squeak Language Modules 0.0003), but a user of the
module, attempting to assemble a working configuration could also write
a "load spec" (and we could formalize what that is) that would bind
#Modules to #(Squeak Language Modules 0.0004).  Eventually, the
hierarchical virtual repository thingie could keep information about the
module substitutions that have worked for people (i.e. I could report
that #(Squeak Language Modules 0.0004) appears to work as a substitute
for #(Squeak Language Modules 0.0003) in ModuleTool).

> But it sounded as Stephen wa talking about having "the old" 
> references still point to the "old" name but the new ones 
> (after having added the extra neighbor) point to the new 
> name. Uahh! That sounds SCARY to me. How would I know what it 
> points at by reading the code? Perhaps I misunderstood.

That's why I mentioned that you'd want to highlight such cases in the
source.  But, you're right...better to avoid that situation.

> My view is that if people insist on still having implicit 
> references EVEN THOUGH there are multiple neighbors exporting 
> the name - it would rely on the ordering of the neighbors for 
> lookup (as Henrik noted). But I would actually propose to 
> have a Preference to disallow such implicit references (and 
> in those cases enforce explicit references) - and the default 
> setting for that Preference would be True.

I think this is still a little pre-carious.  I would rather use internal
names to reference the external modules, and be explicit about the
binding.  Implicit binding based on the order of modules is too
whimsical for my taste.  I think it would certainly lead to confusion.

- Stephen




More information about the Squeak-dev mailing list