Why not share the code? Just use a "cell" to hold the class and have methodClass accessor do the indirection.
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. Just think of the a trait method as a closure which is parameterized on the class. Am I missing something deep here? -KenD > Message: 7 > Date: Wed, 21 Oct 2009 09:41:08 +0200 > From: Adrian Lienhard <a...@netstyle.ch> > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits > To: The general-purpose Squeak developers list > <squeak-...@lists.squeakfoundation.org>, Pharo Development > <pharo-project@lists.gforge.inria.fr> > Message-ID: <3c7e5c51-21a8-483a-81a0-40854430a...@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
