>
> No, no, no. A "variable" is a name in Smalltalk not an object. Because 
> of
> that there is absolutely no reason for "recompiling an entire class
> hierarchy" unless you bind the name to a "slot" which is represented 
> as part
> of the object. For example, you might *easily* stick that slot into a
> dictionary (such as Morph's extensions) and simply tell the compiler 
> that
> what it should do when it sees the name "foo" is to send messages like 
> #foo
> and #foo:. At which point, when you load the package you merely tell 
> the
> compiler about that "variable" so the compiler knows what to do when it
> comes across the places where foo is used, and when you unload it you 
> simply
> remove the methods (if you want to be pedantic you can remove the 
> values
> too).

sure in moose I was thinking to introduce the use of dictionary but 
this is not what I would like.

>
> But most definitely there's no reason whatsoever to recompile an entire
> class hierarchy just because you told the compiler that it's okay to 
> use
> "foo" as a name in some portion of code. The behavior we see today is 
> simply
> the result of having only one, and heavily optimized, way of 
> representing
> variables.

Yes but my point is can we find a clever way to use the same optimized 
way
to support state extension. I do not like the idea to really on 
dictionary.

stef

>
> As for George's note about adding a variable to Object - precisely the 
> same
> could be done here. So if we wanted to add a "variable" to Object all 
> we
> need to do is to tell the compiler that (for example) it should use 
> the name
> "dependents" to refer to
>
>     DependentsFields at: self
>
> and be done with it (there are some subtleties with the above which I 
> won't
> discuss in detail here - see the above as a conceptual example). So 
> there's
> a significant difference between a "variable" (representing a name we 
> can
> use in some program) and its associated "slot". If you want to add a 
> "slot"
> to Object, yeah, you'll be screwed in Squeak. But adding a *name* under
> which something is accessed is no problem whatsoever (except that the
> current compiler doesn't support it ;-)
>
> Cheers,
>   - Andreas
>
>