On 27 February 2010 18:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Feb 27, 2010, at 5:12 PM, Igor Stasenko wrote:
On 27 February 2010 10:11, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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>
This is an object memmory layout - a pair of two oops(object pointers) one following other - Â key and value.
yes I got it.
My point is still valid
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.
You mean that morphs could add arbitrary slots to its instances? Why difficult? This extension is to match the object format of Self and JavaScript.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.