Extension methods vs. Traits

Daniel Latrémolière daniel.latremoliere at gmail.com
Fri Dec 11 06:40:19 PST 2009


I suppose implementation of the extension method need to add bytecode 
describing a new slot type forwarding calls of the extension method of 
this slot on a non-abstract method of another class (modification of the 
linker). Others methods can possibly cause problems like those of Scala 
traits.

Given that, I think the modification needed to the linker for supporting 
traits, can not be bigger than the modification to the linker for 
supporting extension method, because I think a trait can be implemented 
with an interface using this forwarding slot and an anonymous class for 
non-abstract methods. Then, I would like to understand the comment of 
the proposal on significant change in the VM needed for supporting traits.

Daniel.
> Hi All,
>
> Traits as 
> proposed, http://www.artima.com/weblogs/viewpost.jsp?thread=220916, 
> are slightly different than Scala Traits:
>
> 1. In Scala if you add a new method to a Trait then you need to 
> recompile classes that use that Trait for the new method to become 
> available, in the proposal the linker adds the new method 
> automatically (hence no need to recompile). Note if you just change an 
> existing method in Scala, or for that matter with the Trait proposal, 
> you don't need to recompile (this is not quite what Alex said - but I 
> think this is what he meant - Alex please confirm).
>
> 2. In Scala you can only access your immediate super Trait, in 
> the proposal you can access any super Trait (this was one of the 
> original motivations behind Traits as opposed to mixins - 
> http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf 
> <http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf>)
>
> 3. In Scala the traits are like mixins with complicated rules for what 
> gets called if the same trait appears multiple times in a hierarchy 
> (diamond problem), in the proposal you have to override any method 
> that is ambiguous (thus much simplifying both the implementation and 
> use of Traits).
>
> 4. Like Scala: the proposal is mainly a modification to the compiler, 
> I would suggest that the compiler work would be similar to adding 
> extension methods. Unlike Scala: in addition to the compiler the 
> linker needs to be changed, so probably on balance slightly more work 
> than extension methods.
>
> I think Traits, as proposed in the blog referenced, would be superior 
> to any of the extension methods (thats why I made the suggestion!) and 
> I would be happy to work on their implementation if people thought it 
> worthwhile. On the other hand, if for all intents and purpose the 
> decision has been made to implement extension methods then there is no 
> point working on Traits.
>
> What do people think?
>
>  -- Howard.



More information about the lambda-dev mailing list