[Pharo-project] Quasi-stateful traits?
siguctua at gmail.com
Fri Feb 26 18:39:51 EST 2010
One of the ways of introducing a stateful traits is changing the VM
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
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
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
Igor Stasenko AKA sig.
More information about the Pharo-dev