At 02:54 PM 2/15/99 -0600, Les Tyrrell wrote:
>Regarding class references, object references, etc... this
>mechanism exists in VisualWorks under the guise of the VariableBinding.
>However, I would imagine that using ordinary Associations is
>acceptable, to an extent.

Yes. Associations had been used in previous versions of VisualWorks. In
fact, the object can be anything that understands the #key, #value and
#value: messages. Instead of the VM accessing the association directly to
get the value, it uses normal message sends of #value and #value:. This
makes it easy to build new tools. Kent Beck had an article in the Smalltalk
Report that would dynamically load classes whenever you executed code that
referenced the class. He did this by overriding the #value message.

>VW craftily handles undefined classes by dumping the VB into the Undeclared
>pool, and whenever a new class is defined, the Undeclared pool is checked
>and the actual VB is transferred to the System dictionary ( Smalltalk ).
>There is no need to recompile anything as all methods, whether defined
>prior to or after the definition of some class, reference the VB and not
>the class, and the VB is transferred out of the Undeclared pool and into
>Smalltalk. 

Squeak also does this. If you have a class that references non-existent
variable #X, and then you define X. It will move the variable from the
undeclared dictionary into the Smalltalk dictionary.

>I believe that only when a class is defined prior to it's
>superclass do methods have to be recompiled, and then only in certain
>cases, not all.

I don't understand this. If you execute:
-----
Foo subclass: #Bar
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Asdf'!

Object subclass: #Foo
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Asdf'!
-----
You will get Bar with a superclass of nil, which is the same as I get in
Squeak.


John Brant