orthogonally to traits I sometimes would like python like hash based (but class
and not object) semantics
ie
Object dictionaryVariable: #MyClass
Igor now one of the problem is see with the possible to add and access slot
everywhere is illustrated by morphic code
when a method add a property extension to a morph, another tests for its value
and the third one remove it.
You get code that is really difficult to understand.
> <key1><value1>
> <key2><value2>
On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote:
> One of the ways of introducing a stateful traits is changing the VM
> object format.
> There is a bits in object's header reserved for identity hash.
> Instead of putting the identify hash value there, we could use it to
> indicate if given object has additional arbitrary slots following the
> object contents:
>
> <header>
> <ivar1>
> ...
> <ivarN>
> <variableVar1>
> ...
> <variableVarM>
> <key1><value1>
> <key2><value2>
> ...
> <keyK><valueK>
>
> so, these keyN->valueN forming a dictionary of key/value pairs, which
> can be accessed using new primitives #slotAt: and #sloatAt:put:
>
> slot allocaiton can be expressed as:
>
> newObject := object copyWithSlot: key value: value.
> object becomeForward: newObject.
>
> (except that this is done by VM primitively).
>
> Once slots is allocated, object size is not grows anymore (so there
> are no overhead) and as bonus, you getting a way to attach any
> additional state to virtually any objects (except smallints) , for any
> purposes.
> Identity hash is become slower, but only at first hashing attempt.
> (slotAt: #identityHash put: value)
> But as benefit, we could use any object (or just 31 bit small integer)
> for hash values, which will increase the hashing quality considerably.
> So, it is a question, what will be faster, especially for large
> dictionaries.
>
> Obviously, then traits free to use this to keep own state, without any
> extra demands from classes where it installed:
>
> foo
> ^ self slotAt: #foo
> foo: value
> self slotAt: #foo put: value
>
> Also, I think that with such extension, we might expect a considerable
> speed boost for Magma OODB, which can use additional slot for marking
> objects by own ids, as well as for marking object dirty, instead of
> maintaining a huge and ineffective IdentityDictionaries to track the
> objects state.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
