[squeak-dev] Re: dynamic state?
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:
> 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.
More information about the Squeak-dev