On Fri, 28 Jul 2006 09:14:00 +0200, Craig Latta wrote:
...
> shared variables and compilation/execution
...
> 	I propose to make the compiler use the classes' notion of names
> directly, so that there is only one naming scheme, and that the classes
> themselves are responsible for it. To do this, instead of storing a
> class' name symbol in its "name" instance variable, we can just store
> the shared-variable association that the compiled methods use (and which
> used to be in the system dictionary).

Interesting idea.

> 	When the compiler wants to find a class with some name in some source a
> human just wrote, it can search the class hierarchy from the root (class
> Object).

Then you'd break with today's capabilities: if a class/subclass relation  
is broken, today one can use compiler to fix it. I'd suggest a search like

  nil systemNavigation allObjectsDo:
   [:oop | (oop isBehavior and: ['HtmlFileStream' = oop name])
	ifTrue: [^ oop]]

Also does less bytecodes than ... subclasses do: ...

I always thought that the subclasses instance variable is superflous  
because the superclass variable serves the same purpose (via indirection).  
It's only convenience (and performance penalty if subclasses where not  
maintained). Of course, garbage collection may also have played a role:  
who references a subclass which doesn't have instances (which themselves  
are referenced).

This, BTW, raises an interesting question: without a "global" which refers  
to your root class, what is it (in your system) that keeps classes from  
being garbage collected?

> the root class
>
> 	As you might guess, this means that Spoon will not have multiple root
> classes. So far, all the non-primary root classes in Squeak were
> motivated by a desire to use method lookup failure for various
> "proxyish" features. I support such features in Spoon directly with the
> interpreter (see for example, class "Other"), so it's not necessary to
> have more than one root class (it's also not necessary to have the
> "ProtoObject" class).

Living in Switzerland, I'm be more neutral. In the 90's I've reviewed a  
DigiTalk project here in Switzerland (someone from Georg Heeg might  
remember his trip to Zuerich) in which all the main components started  
with " nil subclass: # ". My comment: if that makes them happy ...

Also, the software research community would most likely want a system with  
multiple root support for their experiments, FWIW.

...
> other shared variables
>
> 	Anyway, back to the system dictionary. I addressed the associations
> there that refer to classes, but there are others. These are the other
> so-called "global" variables (like Display, the primary display) as well
> as all the "shared pools" (like TextConstants and, strictly speaking,
> Undeclared). I think each global variable should be the responsibility
> of some class. So the primary display could be something you get by
> sending "primary" to DisplayScreen.

+ (1 Big)

> 	Shared pools are dictionaries of shared-variable associations, similar
> to the system dictionary (in fact, I'd call the system dictionary just
> another shared pool). I know some think we should simply banish all
> shared pools, but I'll assume for the moment that we're keeping them. I
> find them useful, I just think some class should take responsibility for
> each one. I've added a "publishedPools" instance variable to Class,
> which stores all the shared pool dictionaries for which a class has
> responsibility (i.e., the class that introduced the pool into the
> system). I renamed the traditional "sharedPools" instance variable in
> Class to "receivedPools"; these are the pools that a class merely uses.
> Finally, I renamed the "classPool" instance variable to
> "classVariablesPool", just to be clearer.

Yes, "shared" pool responsibility is long overdue.

> 	When you want to use a shared pool, you access the pool by sending a
> message to the responsible class, rather than relying on its name being
> a global variable.

+ (1 Big)

> method references to "Smalltalk"

I'd appreciate you make them all go away, regardless how :-) What if the  
next private investor wants to have #Squeak as name instead of #Smalltalk  
<grin/>

...
> 	Again, thanks in advance for any feedback or questions.

And thank you for sharing your thoughts and plans.

/Klaus