[Pharo-dev] Losing instance variable addition

Frank Shearar frank.shearar at gmail.com
Fri Nov 1 04:44:18 EDT 2013

On 1 November 2013 03:36, Stéphane Ducasse <stephane.ducasse at inria.fr> wrote:
> On Oct 31, 2013, at 11:37 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> Btw, if you remember, i already proposed how to solve 'extending object's state with arbitrary state' , mainly by changing the object format to support variable number of key-value properties per object.
>> Similar to javascript or self, where you can define a new property on a per-object basis.
>> This is fairly easy to implement, at VM level, just reserve extra field in object format,
>> define the format of key/value dictionary and add primitives to retrieve and store key-based properties for objects.
>> What i like in it, that at language side it is cost nothing: you don't have to extend
>> the language to formally define the slots (but you may, of course),
>> and there's nothing preventing you from using private keys and not giving them away
>> to anyone to keep your data private and not exposing it globally (except from reflection tools i guess).
>> And, what is important, you are free to use them or not.. and it costs almost nothing in terms of performance, and nothing in terms of formalism and extra rules in language/package/source management etc etc
> you do not need to be at the object level. For me this would be another level of mess.
> When you think about class extensions we get them because methods are not in the scope of the their class
> so it was easy to define a method into a file that represented another changeset.
> Now we have problem with iv extensions because they are scoped by the class definition.

Does this imply that the correct scope for a class extension would be
per package?

Say package Base defines a class Foo and package Ext adds a slot to
Foo, could you model this through an (Squeak) Environment-like way
like this?:

In your application's Environment Env, Foo is as it's defined by the
Base package. When you load Foo into Env, Env stores a _subclass_ of
Foo Foo1, adding the slot to Foo1. But Env actually maps Foo1 to Foo.
Within Env, looking up "Foo" means finding Foo1, with the extension.
In any other Environment, looking up "Foo" finds Foo, without the

(This is how I think extending classes with methods should work too,
but I'll be the first to admit that this idea is a "what if we..."
idea without any real thought into how feasible it is.)


> Stef
>> --
>> Best regards,
>> Igor Stasenko.

More information about the Pharo-dev mailing list