Hi Martin,
 even though you change the implementation of the message #class, the
behavior you expect will not work because the method lookup algorithm access
the class field of the object header directly. So, what you really need is a
way to change that field, like a primitive (something VisualWorks and
VisualAge have. I don't know about Squeak...)
 Alejandra De Bonnis has implemented instance behavior as part of her
master's thesis, adding a new field to the object header that points to a
"message reception strategy" and changing the VM's method lookup in this
way:
1) If the receiver's message reception strategy IS NOT nil, send the message
#value: to the message reception strategy with the original message as
argument (*).
2) If the receiver's message reception strategy IS nil, and the receiver's
class message reception strategy IS NOT nil, send the message #value: to the
receiver's class message reception strategy with the original message as
argument (**).
3) Else, execute the normal method lookup (GLC in case of Squeak).

(*) The message reception strategy is a "first class object". That means
that you can implement in Smalltalk the behavior an object should have when
receiving a message. It also means that special care had to be taken to
avoid an endless loop. Our decision was to prohibit to specify a message
reception strategy for those objects that represent a message reception
strategy.
(**) We did this because we wanted also the possibility to change the
behavior of all instances of a class at once.

I don't remember the right numbers on performance, but the impact was not
big at all when no special behavior was configured.
About memory, a word for each object was added, not that bad...
She created some specials tools to manipulate this characteristics
(inspectors or browsers,  I don't remember exactly)

If you want, we can provide you the image, vm source code, etc.
IMHO, changing the VM is the best way to implement instance behavior, no
need to rely on DNU, proxies, etc. This approach reifies message reception,
therefore you can do what ever you want when an object receives a message.

Bye,
Hernan.


 What we did is:
1) Add a new field to the objetct


On Nov 13, 2007 7:56 AM, Martin Beck <martin.beck at hpi.uni-potsdam.de> wrote:

> Bert Freudenberg schrieb:
> >
> > Wouldn't overriding #class break more things than it solves? After all,
> > your object's class is not what it would claim to be.
> >
> > Which "normal behavior" would you like to "retain"?
> Infact, we don't want to override Object>>#class but the #class in our
> generated anonymous class. It would look like this:
>
> AnonymousClass>>#class
>        ^self baseClass
>
> So normal system behaviour is not changed, only if you alter an instance
> by for example adding a method, an anonymous class in the class chain is
> inserted which overrides the #class method. One reason to do this, is
> that the CodA paper specifies this behaviour, too. Another one would be,
> if somewhere in the system instances are tested for their classes (which
> shouldn't be the case...).
>
> But it seems, that this is not possible in an easy way...
>
> Regards,
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20071114/f85f4ef3/attachment.htm