On 23 March 2010 19:16, 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.
>
About traits, it was just an example, how new object format could be
used in combination with them.
If you going to add state to traits explicitly, then you will need to
change the trait definition format (to include used ivars etc),
as well as design schemes to handle name conflicts. =>> more complexity.

But named slots don't require from traits to change anything in that
way. Traits will still stay to be a simple
set of methods without any additional formal specs/rules.

> 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).
>
Yes. In general , this is a way to attach additional state to any
object (or to subset) in system.
Btw, identity hash is one of the cases, where you want to support this
property globally,
but don't need to make it mandatory, because for objects which not
used in hash-based collections,
this property is redundant.
So, initially , a generic object could be created without identity
hash slot, which is then added
dynamically, once identity hash requested.
But some objects could pre-allocate slots upon creation. For instance
- Symbols could be initially created with identity hash slot,
with value set to the hash of its string value.

> 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.
>
if by 'properties dictionary' you mean storing it in an extra object -
then it is different to what i proposed.
In format , which i proposing, a dictionary of key/value pairs is held
within an object (it is not accessible as a separate object from
outside).
This is similar to Self or JavaScript object formats, where object is
a set of named slots.

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