On 27 February 2010 18:44, Stéphane Ducasse <[email protected]> wrote: > > On Feb 27, 2010, at 5:12 PM, Igor Stasenko wrote: > >> On 27 February 2010 10:11, Stéphane Ducasse <[email protected]> >> 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 >>>> [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 >>> >> >> >> >> -- >> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
