[Vm-dev] [Pharo-project] Plan/discussion/communication around new object format

[Igor Stasenko]

On 16 June 2012 07:45, Colin Putney <colin at wiresong.com> wrote:
>
>
> On 2012-06-15, at 7:28 PM, Igor Stasenko wrote:
>
> In theory yes, but in practice, existing object format(s) do not allow
> you to do that:
> try adding instance variable to any variable class with bytes/words format.
>
>
> It's worse than that - if you add an instance variable to Object, it changes the layout of Behavior instances. That instantly crashes the VM, because superclass pointers and method dictionaries aren't where the VM expects them to be.
>

Yes, that's why i stressed that arbitrary properties is not a slot,
which should be 'known' by an object itself,
because most of the times the object in question don't needs to have
direct knowledge of the nature of properties stored there.

This comes from the the problem of adding properties, which can come
from completely different, often anonymous layers of system or
frameworks: you can never know what idea could come into mind of
another framework developer and what additional state(s) he may need
to store per object.

Lets just consider a single example with hash: imagine that we removed
Sets and Dictionaries from our language. In such system, objects no
longer need to be able to care about their "hash" property, since
there is no any users of it. Apparently that means that hash property,
is an external property to all objects in system, and mean something
only to Sets and Dictionaries which know how to reason about it.

> Levante has a point, though. Management of the properties dictionary doesn't have to be implemented at the VM level, it just has to support a named instance variable in Object.
>

Err, where i said anything about dictionary? VM just knows that all
objects on heap will have at least one reference slot, aside of other
references (ivars/variable vars etc).
So, you will need only 2 primitives from VM side to access it: read
slot value and write to that slot.
The rest is completely up to language side to decide what to do with
it. Shall we use dictionary to store properties there? Most probably
yes.

> Colin
>



-- 
Best regards,
Igor Stasenko.