----- Original Message -----
From: Chris Becker <chb99 at msn.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Saturday, February 23, 2002 9:28 AM
Subject: RE: [Modules] Upper case message names for accessing modules


> In your example, how would you find MorphicEllipse in the system browser?

Well, that rather depends on what you mean by the word "system", doesn't it?
I can only describe what I had thought would be the case in Oasis ( and
perhaps someday will be, granted the time needed to do this ).

In Oasis, the module in which you referred to MorphicEllipse would contain an
Undeclared reference to MorphicEllipse.  It would not know that MorphicEllipse
represented a class- there is no evidence in the code to support any such
inference ( not even sending it #new is enough to guarantee this ).

However, the approach I had intended to take with Oasis was that Modules would
remain totally independent entities, but could be "assembled" into Systems.
Thus, there is a higher level of organization that I had intended to
introduce.   In that case, a System would actually be aware of the fact that
one module requested something which it called MorphicEllipse, and that
another provided a class which it had bound to a variable called EllipseMorph,
and through the magic of automation and human interaction, would know that
these are meant to be connected.  Thus, the System would know that there was
something called MorphicEllipseMorph ( ie, the class EllipseMorph in the
module named Morphic ), and your "System" browser would see it as such.

In other words, at the System level you the programmer would be totally
unaware of the existence of namespaces/modules.  But you would have the tools
to see the System as a collection of Modules, and your view of each Module
would be somewhat different than that offered at the System level.

The more interesting case is of course when you have *two* modules named
Morphic, and they are merely different variations of one another... but in
that case, it seems you would be unlikely to want to assemble them into the
same working System, so I haven't given that case much thought.  However, it
is very often the case in Oasis that I have two browsers open, one on the
regular Smalltalk world and one on an OasisModule containing another Smalltalk
world- in those cases, I have to double check carefully before I glibly
redefine Object.  ( this is basically a tools issue ).

Otherwise, even if you were to name a class in your module
MorphicEllipseMorph, it would still be disambiguated by the system as
MyModuleNameMorphicEllipseMorph.  And in practice, this is basically what
Smalltalkers have been doing on a manual basis for years.

> Would MorphicEllipse actually become the name of the class when you
> loaded/installed the module?

In your module, it would still be called MorphicEllipse.  It would only be
known to your module as an Undeclard ( or, more properly, an Unbound- in a
living, dynamic system the notion of Undeclared really means "not yet" or
perhaps "used to be").

> If not, this would still be confusing because
> you can't look at the code and tell what is a class with a module prefix,
> and what is a simple class name.

Strictly speaking, this is the case that has already existed for decades in
every single pre- *AND* post-namespace Smalltalk file-out.  There is NOTHING
in these things to tell you *explicitly* that a global reference is referring
to a class object.  Only when you have in the same fileout a *definition* for
either that class, or methods to be added to that class, can you then safely
infer that there is a *class* by that name, not just some global reference to
an  arbitrary object.

What is important about the name is that it be descriptive and semantically
meaningful and consistent within the context of the module in which it
appears.  It should be enough, and no more.  If you are in the context of
graphical objects that know how to draw themselves, say "Ellipse".  It's good
enough.  But if you are in a context where sometimes you mean the geometric
entity having certain geometric properties, *AND* something else that knows
how to draw itself on a certain kind of display device in a certain way that
highly resembles said geometric entitity, then name them accordingly- eg,
"Ellipse" and "EllipseMorph".  Otherwise, at the System level they can simply
become "MorphicEllipse" and "GeometricEllipse" automatically.

Everything else is just a tools issue.

> Whew! This is tiring, isn't it? Eeek!  :-P

If I had thought I knew enough about this stuff to really push hard for my
solutions, I would already have done so- Smalltalk has many unique
characteristics that take a bit of hard looking and thought.

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

- les