On 21.10.2009, at 22:28, Ken.Dickey wrote:
Why not share the code? Just use a "cell" to hold the class and have methodClass accessor do the indirection.
But based on which info should this indirection be made? The idea with a simple backpointer was done because it's already there in case of super-sends. So you would need to do something special there again (the last literal *has to be* a class for those methds).
If you have a bit in the method header, the VM could use it as a 0/1 index into the code to call to do (or not do) the extra indirection.
If there is something that is a scarce resource, than it's bits in the method header. And I don't get it: there is one header per object, not one per reference. Thus the bit could not be diffrerent per *use* of the compiledMethod.
Just think of the a trait method as a closure which is parameterized on the class.
Am I missing something deep here?
You overlook complexity ;-)
-KenD
Message: 7 Date: Wed, 21 Oct 2009 09:41:08 +0200 From: Adrian Lienhard <adi@netstyle.ch> Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits To: The general-purpose Squeak developers list <squeak-dev@lists.squeakfoundation.org>, Pharo Development <pharo-project@lists.gforge.inria.fr> Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B@netstyle.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
I've fixed this issue in Pharo a couple of months ago. CompiledMethods are not shared anymore, so methodClass returns the expected class. At the time I implemented traits (2004?), there were no method properties and hence sharing compiled methods worked -- of course except for super sends in which case the method was always recompiled (so the answer to Andreas' question below is b)).
Cheers, Adrian
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project