[squeak-dev] Re: dynamic state?

Andreas Raab andreas.raab at gmx.de
Tue Mar 23 17:16:02 UTC 2010

On 3/23/2010 9:49 AM, Chris Muller wrote:
> Hi Igor, I was interested by your suggestion in this message:
>    http://lists.gforge.inria.fr/pipermail/pharo-project/2010-February/022526.html
> I thought it sounded neat because it would seem to bring "dynamic
> state" to objects.  Objects wouldn't have to rely on instVars defined
> in classes to extend state, all while providing logical solutions to
> some of the issues like immutability and 12-bit identity-hashes..  Is
> it a good idea?

It's an interesting thought, but I'll make a few observations: First, 
the usage with traits seems odd. For traits you have an explicit 
composition step already, the step can compute required state and add 
that to the class in question. So the original motivation is a bit off.

Secondly, I think that because traits don't need 'em, the slots should 
be like any other indexed slots, and should have a global meaning (such 
as slot 1 is identity hash). Of course, then you can just go one 
additional step and say that one such slot is the class slot. That gives 
us two known slots that we'd like to have in any object (class and 
hash), I'd add a third one: a generic dictionary of properties so that 
you don't need to add external registries to hold onto associations 
between instances and properties and the associated GC issues (ephemerons).

And of course, if you don't have high performance requirements, you 
could use just a single bit to indicate that the object has additional 
properties and use the properties dictionary to store all additional state.

In short, I kind of like the idea for designing a fairly compact but 
extensible object format. It would mean some major restructuring of the 
object format but it's worth thinking through it to find out what other 
issues this could help with even if implemented differently.

   - Andreas

More information about the Squeak-dev mailing list