At 11:35 -0800 2002.02.23, Les Tyrrell wrote, in response to Chris Becker"

>  > OK, so *now* I'm realizing that having module path references in your code
>>  is just going to lead to problems anyway. If the module path changes, your
>>  code is broken. Just like if you have hard-coded paths to files in a program
>>  and someone moves the file. Reorganization happens often, so this is bound
>>  to occur.
>
>Oh yes.  Very frequently.  Squeak in particular has an extremely high
>evolutionary rate.  Whatever is done in Squeak will have to accomodate this.
>
>>  So I'm hoping we will not have to use the module paths to reference classes
>>  in our everyday code.
>
>I very emphatically agree!  That said, as I have mentioned earlier in this
>post, had I thought that I had *the* answer to these problems, I would already
>have posted them long ago.  As it is, I've only commented when I've seen this
>stuff come up over the years.

Perhaps its a bit late to poke my oar in here, but I agree too.  In 
addition to modules, we need a way of connecting together modules to 
make systems.  That is, we need a module interconnection notation, 
which we can use to express what is sometimes called a 'system 
model'.  This model is where the fact that we want to build a system 
containing a particular version of the morphic ellipse class goes -- 
not in a module that uses an Ellipse morph.

Although I'm convinced that this is the "right" answer, the problem 
is reconciling this view of with Dan's initial goal of not 
complicating things for the weekend hacker (of which IO am one). 
Having to build a "system model" for each new piece of code that you 
want to add in would certainly complicate things.

I think that perhaps one solution to this is a tool that builds the 
configuration for us.  The obvious thing is to do name matching: if a 
module uses an undefined global (like Ellipse), the tool would simply 
search all of the other modules hat it knows about -- maybe all of 
those in a web-based repository -- and find the places that define 
something called Ellipse (which might or might not be a class, given 
Smalltalk's lack of type declarations).  If there is more than one, 
it might ask me which to choose, or it might apply some heuristics.

The danger with this, of course, is the same as the danger with Unix 
paths -- you will sometimes get the wrong version and not know it. 
Which is why I think that it is really important that the tool 
generate an explicit system model that binds all of the otherwise 
unbound names, and that WE CAN BROWSE the model that it outputs. 
Maybe the output is just a method containing a bunch of assignments 
like

	Ellipse := ModuleReference at: #Squeak at: #Morphic at: #Core 
at: #Basic at: #Ellipse

or maybe it is something more complicated: what's important is that I 
can browse it and EDIT it to change my system configuration.

In this context, the question that started this thread, which is 
whether I should be able to write

	Squeak Morphic Core Basic Ellipse

rather than

	ModuleReference at: #Squeak at: #Morphic at: #Core at: #Basic 
at: #Ellipse

or

	ModuleReference new: #(Squeak Morphic Core Basic) class: Ellipse


or whatever, is really not all that interesting, because these 
expressions don't clutter up my code.  Personally, I would favour a 
ModuleReference class that did the work of name lookup, and a helper 
methods in Array that made it palatable, such as

	#(Squeak Morphic Core Basic) asModule

or

	#(Squeak Morphic Core Basic Ellipse) asClass

or even

	'Squeak Morphic Core Basic Ellipse' asClass


(asModule and asClass would actually do some checking that the thing 
that they found was actually a kindOf module or class).  But the 
important point is that I don't have to write any of these ugly 
things most of the time, and I don't have to read them either.

	Andrew