[Pharo-project] Quasi-stateful traits?
stephane.ducasse at inria.fr
Sat Feb 27 03:11:58 EST 2010
orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics
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.
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:
> 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
> 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
> Obviously, then traits free to use this to keep own state, without any
> extra demands from classes where it installed:
> ^ 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
> Pharo-project at lists.gforge.inria.fr
More information about the Pharo-dev