On 23 March 2010 22:43, Chris Muller <asqueaker at gmail.com> wrote:
> 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..
>

Yes. In particular, i'm also mentioned Magma, which could benefit from
this format
- you could add a named 'magmaOId' slot to any object of interest, by
simply implementing:
Object>>magmaOId
  ^ self slotAt: #magmaOId ifAbsentPut: (MagmaOidGenerator newId)

(and #slotAt:ifAbsentPut: is a primitive, supported by VM).

So, you don't have to maintain a separate dictionary of 'object->id',
having a multiple thousands of elements,
and because of small identityHash (12 bits) values size, is one of the
bottlenecks, making it slow.

>
> 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
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.