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
