Ah, I should have mentioned that I was interested in Igor's idea from
completely _outside_ the context of Traits and his original message
purpose.  I know nothing about Traits have no interest in learning
them.  I was only wondering whether his idea was useful as a
general-purpose change for Squeak..


On Tue, Mar 23, 2010 at 12:16 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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.
>
> Cheers,
>  - Andreas
>
>