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