Re: [Pharo-project] Remove #class as a Compiler optimization
On Mar 25, 2011, at 7:09 PM, Toon Verwaest wrote:
What do you think?
I am for... for the JIT is is a monomorphic send to a primitive, so the IC will be very effective and should take care that the lookup is actually almost never done. (and the lookup is the only thing the #class bytecode saves, as the target method is a primitive). I think that programmers should have the illusion that the VM interacts with the system through message sends. By being able to overwrite this particular message you break this illusion.
Why that? I think exactly the opposite is true. If I write self class I think that I send #class to self. But in the current system I do not. If #class is not send, one can never ever do proxies that work for real. A proxy can never stand in for an object as #class always answers "Proxy", even though it should not. Or for a Future it will say "Future".
The VM will just fetch the real class; but the user doesn't get access to it anymore. Telling the system that this particular message shouldn't be overwritten is probably a good thing.
One should take care, but a system that just does not allow things like this *even if you take care* is bad.
If you want to overwrite the method class, maybe your tools should send another message than class in the first place?
So what if it's not a tool? It might be domain code that really does self class == something as part of execution. Now I want ot use a proxy here, but I can not. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
participants (1)
-
Marcus Denker