[squeak-dev] Re: dynamic state?
siguctua at gmail.com
Tue Mar 23 21:08:24 UTC 2010
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
- you could add a named 'magmaOId' slot to any object of interest, by
^ 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:
>>> 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
Igor Stasenko AKA sig.
More information about the Squeak-dev