[Modules] Upper case message names for accessing modules

Hannes Hirzel hirzel at spw.unizh.ch
Mon Feb 18 18:42:37 UTC 2002


On Mon, 18 Feb 2002, Henrik Gedenryd wrote:

> >> You can also send uppercase messages to a module to access its
> >> submodules. So if moduleA has a submodule named ModuleB:
> >> 
> >> moduleA ModuleB
> >> This will return the submodule. Ie. the message is the exact name of the
> >> submodule.
> >> </citation>
> 
> This was actually Dan Ingalls' suggestion way back in the earliest phase of
> the last modules discussion round. I had a different suggestion that may
> well be buried and forgotten!
> 
> >> 
> >> I don't like this idea. It sacrifies regularity of the syntax for a tiny
> >> benefit.
> 
> It's always easy to dis an idea, and it's especially easy to dis new ideas
> and say that you like the old way better. It is however more difficult to
> produce better solutions. In particular, the position "I want modules but I
> also want everything to stay exactly the same as it was before" seems to
> come up surprisingly often.

On of the goals of the modules system is to change as few things as
possible. Therefore it's totally viable to question this.

 
> So, what do you suggest instead? I hope you realize that inter-module name
> references are a new construct, and a new convention is needed for making
> them. If you try to get around this type of reference, you get into a
> bootstrapping problem.

You didn't hope in vain. I have worked with Modula-2, Oberon and Java.

My point was just: Is it worth the to have the ambiguity of mixing
objects and messages which begin all with a capital letter.

I would prefer the more common
(A)
  ellipse := (Module path: #(Squeak Morphic Core Basic) 
                   class: #EllipseMorph) new

over 

(B)
  ellipse := Module Squeak Morphic Core Basic EllipseMorph new. 


In the form (A) it is obvious that just a dictionary lookup (more
or less) is happening. Instead of one large Smalltalk dictionary we now
have several.






> In general I think Doug's comments were thoughtful
Agreed. They helped me.

> > This would require that your module imports ("uses") the Morphic-Core-Basic
> > module.  I tend to think that this is probably the best practice of the
> > three... assuming there's some sort of reasonable UI for easily making modules
> > import other modules, etc, in as automated a fashion as possible.
> > 
> > In fact, I'd go as far to say that I would always import modules (like example
> > 3) when writing code, and never use explicit paths in my code, the *only*
> > exception being when there's an actual class name clash in my imported
> > modules, and then of course I would need an explicit path in the code.  (I'd
> > be curious to hear other opinions on this, though.)



> - Importing all names has many problems of its own, and indeed you still
> would need the ability to disambiguate somehow. But it is generally
> considered better practice to be explicit about where a name comes from,
> than to import a name. E.g. when creating Oberon, Wirth removed the ability
> to import names like you could in Modula-2.

Well I'm not so sure about this. It is for example generally considered
general practice not to have objects with 1000 methods like Morph but we
learned to live with that and even consider it to be easy to handle
nowadays.

For me the most important benefit of [modules] will be that that the 16MB
image is divided up into several separatly loadable and versionable
subsystem, so that people can easily have different configurations and
that it is easier to add and maintain applications. 
With just one update stream everything may be possibly changed after 
every update.

I re-read the email by Dan Ingalls of Aug-16 2001 where he gives two
reasons of not hard wriring the class references. Is this what you meant?


<long citation> 
There is a reason why I left foreign references interpreted.  It wasn't
for the lateness benefit (ie perhaps changing the binding (but see
below)), but so that we could *invalidate* the binding by swapping a
module out.  This is one of the things that makes the Environments scheme
sort of unusual.

(I)
The idea (and this all actually ran at one time) is that you can swap an
entire Environment out as an image segment.  Then, since foreign
references are of the form
	Envt Thing
an attempt to refer to Thing will cause a message-send to the image
segment root stub, giving Squeak a chance to swap in that segment and
resume the message send.

If you do the binding early, then you have a literal pointing directly at
the association for Thing, and the VM will crank its way into invalid
pointers if the segment is out.  Actually, this won't happen.  Instead the
segment creation machinery will fail to find a swappable region due to the
literal pointers into it.  This can be hacked by making every dictionary
entry a root for the segment, but you still have the problem that the VM
will try to crank its way through invalid stuff on the literal
reference.  This can be further hacked by making every internal referent a
root, but I felt it was in conflict with some basic principle.  When I
stepped back from all this I said "Ah, references to the internals of an
environment can only be made by sending a message," and that's how it
works.

(II)
By the way, it occurred to me that the late binding property *would* be
nice for the following situation:  I have one package called Files, and
another called NewFilesExperiment.  I should be able to just type (after
saving ;-)
	Files := NewFilesExperiment
and suddenly everything in the system should be running with the new
bindings.  I gather this is one of the things people like about packages.

I did think it was pretty cool to get both name spaces and packages in
only a few pages of code, but a lot of the work of browser support,
package dependence, etc., remains incomplete
</long citation>


> But like I said above, what do you suggest instead?
>

If Dan's two points (I) and (II) are possible to easily implement with
(A) then I would still prefer (A).
  
 ellipse := (Module path: #(Squeak Morphic Core Basic)
                     class: #EllipseMorph) new          


If this is not possible, which is probably so, (I) and (II) have enough
weight that I would say the additional explanation effort (conceptual
overloading)  needed for (B) 
  
 Module Squeak Morphic Core Basic EllipseMorph new

is justified although I don't like the idea of having upper
case message names. The Smalltalk syntax has very few distinctions
and this blurrs the distinction between globals, classes and message
names.

I'm aware of the fact that given the great advantages of having the 
[modules] system justifies some changes. However if they can easily
be avoided I would prefer not to have them in this particular case.  	

Cheers
Hannes Hirzel




More information about the Squeak-dev mailing list