Hi Martin,<br> 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...)
<br> 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:
<br>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 (*).<br>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 (**).
<br>3) Else, execute the normal method lookup (GLC in case of Squeak).<br><br>(*) 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.
<br>(**) We did this because we wanted also the possibility to change the behavior of all instances of a class at once.<br><br>I don't remember the right numbers on performance, but the impact was not big at all when no special behavior was configured.
<br>About memory, a word for each object was added, not that bad...<br>She created some specials tools to manipulate this characteristics (inspectors or browsers, I don't remember exactly)<br><br>If you want, we can provide you the image, vm source code, etc.
<br>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.
<br><br>Bye,<br>Hernan.<br><br><br> What we did is:<br>1) Add a new field to the objetct<br><br><br><div class="gmail_quote">On Nov 13, 2007 7:56 AM, Martin Beck <<a href="mailto:martin.beck@hpi.uni-potsdam.de">martin.beck@hpi.uni-potsdam.de
</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Bert Freudenberg schrieb:<br><div class="Ih2E3d">><br>> Wouldn't overriding #class break more things than it solves? After all,
<br>> your object's class is not what it would claim to be.<br>><br>> Which "normal behavior" would you like to "retain"?<br></div>Infact, we don't want to override Object>>#class but the #class in our
<br>generated anonymous class. It would look like this:<br><br>AnonymousClass>>#class<br> ^self baseClass<br><br>So normal system behaviour is not changed, only if you alter an instance<br>by for example adding a method, an anonymous class in the class chain is
<br>inserted which overrides the #class method. One reason to do this, is<br>that the CodA paper specifies this behaviour, too. Another one would be,<br>if somewhere in the system instances are tested for their classes (which
<br>shouldn't be the case...).<br><br>But it seems, that this is not possible in an easy way...<br><br>Regards,<br><font color="#888888">Martin<br><br></font></blockquote></div><br>