Hi, Guys -

Just didn't want to miss out on the fun ;-)...

>"Alejandro F. Reimondo" <aleReimondo at smalltalking.net> wrote:
> > What do you think about sending the name
>>  as message...
>>     MyGlobalContext::ThisClass
>>  becomes:
>>     MyGlobalContext ThisClass
>>  the global context (aNameSpace, anEnvironment
>>  or SystemDictionary)
>>  can respond to the message returning the real
>>  object (or via dnu build a method to return it)
>> Using this "trick" we do not need new syntax
> >  and the solution is solved as usual (sending messages).

...and goran at krampe.se replied...
>Just wish to note that this approach was indeed tested IIRC in the
>3.3modules code, and if my memory serves me right Dan proposed it - but
>I am not sure. Personally I was hesitant at the time, and still is.

Yes, 'twas I.  Here's what I liked and still do like about it:  it is a message-based
interface to independent modules.  I learned a lot from dealing with the direct
links in the superclass chain and global variables, when trying to get the full
advantage out of imageSegment-based modules.
[We can chat another time about the virtues of making superclass pointers
also be message-based rather than direct pointers].

>A few comments:
>
>1. It would move the binding time to runtime instead of compile time (or
>if you prefer to call it "code install"-time).

Yes.  In the Environments rewrite, the modules were first-class objects,
pointed at just like other globals are now.  The class references were
made by sending the class name as a selector to the module.  This
introduces a message send, but it's the kind that most VMs do
blindingly fast.

> I can probably imagine
>both pros and cons with that. It is a big change.

Let me call your attention to a couple of "pros" that I consider to be
quite compelling...

1.  With this architecture it is not only possible, but trivially simple
and atomically fast  to execute, eg,
	OldFiles := Files.  Files := FlowVers2.
One bytecode, and every access to the File module now
goes to the new package under test.  Obviously if something
goes wrong, order is restored with
	Files := OldFiles.

2.  I have always felt that if things are structured right, then "uninstall"
is already provided by the garbage collector.  When you are ready to
get rid of the old file system, then
	Files := FlowVers2.
does the job clean and fast because none of the global references
are direct.

Both of these are valuable, and they're not simple in many
competing architectures.  Or to put it another way, competitors
should be evaluated with these desiderata in mind.

Just as we hope with Spoon, or any other modular build scheme,
to build up a system from a clean load of packages, if the modules
behave right, you should be able *equally simply* to get back
to the kernel by discard methods that do little else than store nil.

Finally, part of my motivation in all this was to establish criteria
that would allow the modules to be stored as image segments
so that the load process could be blindingly fast.  For example,
back when the VM-Construction category was a quarter megabyte
it loaded in less than 100 milliseconds done this way.

>2. In my personal opinion it is less readable than
>MyGlobalContext::ThisClass. It blends into the rest of the code so that
>the reference itself doesn't "stand out"

Well, if we want it to stand out, that's easy enough.  It would be
reasonable to highlight all globals and in this case that would
extend to both parts of a package reference.

> It also deviates from the
>"words beginning with capitals refer to classes (or globals)".

Well, we're doing something new, so something has to change.
I kind of like the convention of capitalized messages being
global and inter-module accesses.

>3. The :: solution actually does not "need new syntax". It just needs us
>to allow $: in global names. Sure, you can call it a "syntax change" -
>but it is very, very small.

I'll grant you that.  Now we just need to convince ourselves that it's better.

Of course any system-wide change like this is a bit scary to contemplate.
But at one time I can vouch for the fact that I had a single method working
that not only changed every global reference so it worked that way, but
also established the kind of hierarchical SystemDictionary that Ralph
refers to (based on heuristics gleaned from the statistics of inter-class
references).  If we get serious about doing this again and want to experiment
with it in a running system as well as doing it bottom-up with Spoon, I'd be
happy to guide people through the reorganizeEverything method that
accomplished this.

I think much was right about Environmnents, but
i think I agree with a criticism Mike Rueger once voiced that the modules
should be as simple as possible, and that building in a hierarchy is
probably not the right thing to do.

	- Dan