It sounds to me like the conclusion was that extension methods aren’t worth it because the use case for them is too narrow to be worth the trouble. So, was it a mistake to add them to C#? Or are there more ambitious use cases in C# that made extension methods worth the cost? LINQ? No one seems to be asking those questions, and that worries me.

Let me clarify something. I don’t think Java should add features just because C#, or any other language, has them. There shouldn’t be any “feature envy”, and every addition to Java has to be justified on its own merits, fit the Java style, pay its own freight, etc. etc.

But we need to be aware of the activity going on over there. Is the lack of a compelling use case for extension methods in Java due to Java’s vision not being ambitious enough?

Java needs to evolve at a faster pace if it wants to remain competitive.

I’m personally only still using Java because I have the inertia of a half million lines of code to deal with. I’d love to switch to Scala.

It’s sad how fast C# is evolving compared to Java.

The “let’s not mess with the language or JVM” ideology is doing serious damage to the Java platform.

I don’t see the value of extension methods. When I heard that use-site extension methods were proposed in a JSR, I felt I had to propose an alternative solution that wouldn’t have the same downsides as the original proposal.

Smalltalk has extension methods and it doesn’t make the APIs easier to understand or use.

Cheers,
Peter

But I don’t see the value gain for extension methods, be they use-site or declaration-site. I must be missing something.

There isn’t anything so awful about Collections.sort(list); that we would need a whole new library mechanism, right? In Java 7, one could add forEach, map, etc. to Collections, and we’d just write Collections.map(list, #(f:SomeType) => expr). Or use a static import.

Is there some usecase that goes beyond this?

you’re right. I haven’t taken this into account, your proposal (and Neal’s proposal) doesn’t need to add new methods. My version would only work for adding new methods.

Regards,

Xavi

With either Neal’s or mine proposals, “list.sort()” compiles to “java.util.Collections.sort(list)”. This would work on older JREs, where as your version would compile to “java.util.List$extension.sort(list)” which doesn’t exist on older JREs.

Cheers,
Peter

I also think your extension methods proposal is very powerful for API implementors. But, could it be even better if the declaration was simpler ? I mean, instead of having to create the extension methods in a separated class and an import to reference those static methods, why not write the implementation of the static method in the interface itself and let the compiler generate a class (like with inner classes) with all the static methods of the extensions? It would be possible to add a mandatory annotation @extension (or similar) to explicitly remark that the method is to be an extension method.

It would be something like:

package java.util;
interface List â?¦ {
â?¦
@extension
void sort(){
// .. Implementation here
this.someOtherMethod();
};
â?¦
}

The compiler would automatically generate a class List$extensions which could contain the implementations of sort and all the other extension methods as static methods. The use of _this_ in the interface extension methods would be replaced by the first argument in the implementation static method:

package java.util;

public class List$extensions {

public static void sort(List list){
…
list.someOtherMethod(); // — this => list
}
}

The rest of the proposal would work exactly as you describe, being compatible with older libraries and so on.

Of course there can be a lot of issues I don’t know, I’m not an expert in compilers, but as a Java programmer for me it would be better to have the implementations in the same interface and let the compiler generate the class where static methods will be.

Only an idea.

Regards,

Xavi

I would very much like to see mixins/traits in Java someday though.

Extension methods are better than nothing, but they are a far cry from ideal.

Why would it be cleaner?

For example, how would adding methods to interfaces work with older libraries? What changes would be required to the Java virtual machine (JVM) to implement your proposal?

After compiling with Neal’s or mine proposals, you get a class file that can run on older versions of the Java platform libraries. Furthermore, both Neal’s and mine proposals require no changes to the JVM because adding a new attribute for the compiler does not affect the JVM (it will simply ignore it).

It would be cleaner though if static methods could be added to interfaces though.

And then just add some syntax sugar so that:

interface Foo {
static int bar( Foo foo, int arg1 ) { return foo.something( arg1 ); }
}

could be optionally written as:

interface Foo {
void bar( int arg1 ) { return something( arg1 ); }
}

Basically any non-static method on an interface would be modified to generate a static method that takes an interface argument as its first argument implicitly.

This would give us extension methods with a syntax that was very mixin-ish. It would also give us the ability to add static methods on interfaces which would be useful in its own right.