( for some reason, my mail client doesn't show > 's indenting Stephen's text )
----- Original Message -----
From: Stephen Pair <spair at advantive.com>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, February 21, 2002 6:33 AM
Subject: RE: [Modules] Upper case message names for accessing modules


I like these ideas.  It would be very nice to be able to write code and
have very explicit knowledge and control over what other modules I'm
basing my work on.

---

Well, explicit control may be something that we might not be able to be rid
of, but I don't like the proposals I'm seeing for making those references...
I'd rather just say "ellipse := EllipseMorph" and be done with it.  Other
tools could be used to provide the explicit definition of what "EllipseMorph"
is supposed to be- I especially don't like modules being aware of the
internals of other modules, even if only to the extent that they are aware
that other modules happen to contain the things they reference.

If you had to do the explict path thing, then why not do some sort of pattern
matching along the lines of: interpreting a name such as MorphicEllipseMorph
as being the tokens #(Morphic Ellipse Morph) which can then be used in a
pattern matching algorithm.  After all, how explicit do you have to get?
Surely it doesn't take too much to make a name unique.  The strictly literal
interpretation of the path/name combination may be a bit of overkill in our
world.

---
Regarding the issue of importing a new module that has a duplicate
export of a symbol that's already being used...maybe the solution to
this problem is to enhance what the compiler is producing.  Rather than
compile in references directly to an association, maybe we should
compile in a reference to something a little more sophisticated...if we
change the VM such that the #value method is actually sent (rather than
make an assumption about having an association), this should be an easy
thing to achieve (and it's arguably the right thing to do regardless).

--------

Right or not, it  is what VisualWorks has been doing for quite a while.  I've
done some experiments in Oasis where I've used this feature to dynamically
redirect the reference to another global.  The overhead of sending #value to
the reference is negligible ( ie, AFAIK not worth worrying about ), since it
is very rare to have anything other than an occasional global reference in a
method.   But by sending a message to the reference, you are allowed to do
some finagling under the covers- one, change the behavior of the reference
object ( basically a slightly modified Association ) so that it will interact
with another object ( which I called a Bridge ) to allow global references in
one module to refer to objects which are maintained in another module.  This
was how I had intended to handle the cross-module global references. There is
more to this that would need to be done- it seemed like a good way to go, but
I've never had time to finish up that inquiry to see if it actually pans out
or not.

- les