[Pharo-project] Quasi-stateful traits?

Stéphane Ducasse stephane.ducasse at inria.fr
Sat Feb 27 11:44:14 EST 2010


On Feb 27, 2010, at 5:12 PM, Igor Stasenko wrote:

> On 27 February 2010 10:11, Stéphane Ducasse <stephane.ducasse at 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.




> 
>> 
>> 
>> 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 at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list