Hmm… maybe your approach was still too far reaching to be a simple change. Maybe making it even simpler would help:

I still think declaration site extensions could have its uses, if you completely forget about having some kind of inheritance available.

This would mean those methods are just available if an object is used through that specific interface/type declaration and thus could not have any collisions with implementing/extending types.

package java.util;
interface List … { …
void sort() import static java.util.Collections.sort; …
}
interface Sortable … {
void sort() import static my.Helper.sort; …
}

class Evil2 implements Sortable, List … { … }
class Evil3 extends Evil2 {
void sort(){ … } …
}
List l = new Evil3();
l.sort(); // == Collections.sort(l);
((Sortable)l).sort(); // == Helper.sort(l);
((Evil3)l).sort(); // == Evil3#sort();
((Evil2)l).sort(); // COMPILE ERROR - Evil2#sort() doesnt exist;

If you wanted to ‘inherit’ the extension methods you would have to declare it by hand in inheriting interfaces (but if you want inheritance you should have made it part of the interface anyway ).
This also could help in declaring functionality which should not be inherited.
So (bad) e.g. you could have a sort method for a general List but not for a sorted list.

package java.util;
interface List … { …
ListIsSorted sort() import static at.mydomain.Collections.sort; …
}
interface ListIsSorted extends List {
//no sort method at all …
}

List l = new ListImpl();
ListIsSorted lSorted = l.sort(); // == at.mydomain.Collections.sort(l);
// sort method is not needed for a list already sorted
lSorted.sort(); // COMPILE ERROR - interface SortedList has no method ’sort’; But supertype List has it as extension method.

I think this feature would be useful _and_ a simple change.

http://www.artima.com/weblogs/viewpost.jsp?thread=220783

Typical usages are:

list -> synchronizedList() -> sort();
list -> { add( 1, “A” ); add( 2, “B” ); };
Home home = new Builder() -> { setWindows( windows ); setDoors( doors ); makeHome(); };

Sure, start off with:

interface X {}
interface Y {}
class XY implements X, Y {}

Then change both X and Y to:

interface X { int m() { return 1; } }
interface Y { int m() { return 2; } }

And XY won’t compile. But I think that is the behaviour you want. The feature allows you to add methods but within limits. And the limits are found by the compiler (or loader) and so you still retain static typing. Problems happen with other proposals, e.g. use-site:

import static XExtension; // XExtension defines m
import static YExtension; // YExtension also defines m
…
X xy1 = new XY();
Y xy2 = new XY();
XY xy3 = new XY();
xy1.m(); // calls X.m
xy2.m(); // calls Y.m
xy3.m(); // Error

Very confusing! They are all XYs after all! Not at all OO!

You can still compile XY, without an error, and a previously compiled XY will still run. Yes this is better from a compatibility point of view, but I think the problems outweigh the advantages.

Declaration-site has the same problems as use-site, just different syntax (which does have advantages - but I am discussing method resolution). Scala style Mixins are very similar to Traits, except that the method to call in the case of a conflict is automatically resolved. So going back to your original example, when m is added to both X and Y using a Mixin:

class XY implements X, Y {}

Is still OK. The class loader adds Y.m to XY since Y is mixed in after X. This would give you the source compatibility you want, but I think an error is better (it will be a rare error and easily resolved and has the great advantage of clarity).

Cheers,

Howard.

Traits and Mixins are not the same. Mixins do not allow multiple inheritance (although they provide the same level of code sharing as with multiple inheritance).

I’m not saying that your proposed syntax breaks existing programs. The motivation for both kinds of extension methods is to mediate the fact that you cannot add a method to an interface without breaking source compatibility. Replay your example in this order:

1. Declare interface X without any methods.
2. Declare interface Y without any methods.
3. Declare class XY without any methods.

Now, lets say you want to add a method m to interface X. Then XY would fail to compile. Your solution is to use traits. Ignoring that we need to change the JVM so it copies method m from X to XY at load time (and work out some rules– which I’m not sure would not have other compatibility problems– for how the JVM does so), it solves the compatibility issue for now.

Then add method m to Y. Now XY fails to compile (which was the entire point of your example). This means that traits does not solve the problem of compatibly adding a method to an interface.

There is a similar problem with declaration-site extension methods. I believe this can be controlled by issuing compile-time warnings and having a tie-break rule. However, I’m seriously beginning to doubt this would be worth the hassle.

The lesson to learn is that there is no such thing as simple language extension to Java.

Wasn’t sure whether to post this on your blog or Neal’s, but anyway:

I’ve been playing around with implementations of methods like curry() with the closures prototype, and have been wondering how best to deal with a couple of issues, namely:
1) I need a different implementation of curry() for n argument functions to the implementation I need for n+1 argument functions.
2) For each of these variations, I’d also want versions which work with primitive types as the arguments and/or result value. Off the top of my head, I think this leads me to something like (9 to the power of (number of arguments + 1)) implementations of curry() for each number of arguments I want to cover. Ouch.

There are a handful of other similar ‘building block’ methods with the same issues. Writing all these implementations isn’t particularly hard - I can write something else to generate them up to some arbitrary number of arguments, and I’ve been implementing them as static methods in a ‘utility’ class, ready for import static usage, but the above issues lead to some practical concerns regarding byte-code size, and usability with code completion features in IDEs.

Ideally I’d want curry() and friends to appear to be instance methods on a function type, but obviously they can’t really be instance methods since function types are defined in terms of single-method interfaces.

Use-site extension methods get around that and make using them a little easier, but solve none of the practical issues.

It occurred to me that declaration site extension methods might offer a way though - the closures spec could conceivably define a handful of extension methods on each function type interface, for example javax.lang.function.OIO might look like:

public interface OIO { // system-generated

R invoke(int x1, A2 x2) throws E;

{int => {A2 => R}} curry() import static javax.lang.function.OIO.Extensions.curry;

protected static class Extensions {
static {int => {A2 => R throws E}} curry({int, A2 => R throws E} fn) {
return {int x1 => {A2 x2 => fn.invoke(x1, x2)}};
}
}
}

I’m not sure how nicely this plays with marker interfaces (such as RestrictedFunction), and the class Extensions should really be private to prevent the static curry method from ‘leaking’ into a closure literal’s scope (Java 6 doesn’t like import static from a private static inner class, for reasons I’m not sure of) - but maybe there’s mileage in this; if these interfaces are to be generated by the VM at run-time (I believe that’s the intention), then we only get as many implementations of curry (or whatever) as are needed, solving the practical issues in a stroke.

Of course the underlying implementation could be different from the above, as long as the function type interfaces can be described in terms of the standard language feature-set.

Mark

Nothing greatly against mixins, I prefer the flat nature of traits and the more explicit conflict resolution. Mixins would essentially be the same in Java, they could even have the same syntax, the only difference would be that class XY implements X,Y {} would automatically get a Y.foo since Y was mixed in last. Either would be good

Where does the proposed syntax break old code? Isn’t everything proposed currently a syntax error? What have I missed?

The implementation technique proposed for traits (class loader adds methods) could be used to allow the user to add methods also (Josh Bloch’s point that it would be nice if the user of an API could add methods). EG:

extension MyList extends List {
sort() { …. };
}

Then in the main class (or at least before List is used):

import MyList; // Not only tells the compiler to use MyList in the file but also extends List at runtime - file that imports MyList must be loaded before a file that uses List - OK to multiply import MyList

1. They look like they do dynamic dispatch, but they don’t.
2. They have a limited use case - statically imported static methods

Perhaps -> could be used and that this notation is for the first argument of *any* method regardless of how its name is made available and this first argument *includes* the hidden this of instance methods. Therefore you could write:

list -> filter( test1 ) -> filter( test2 ); // static void filter(List, Predicate) is statically imported

list1 -> addAll( list 2 ) -> addAll( list3 ); // addAll(List) is an instance method in List

The above notation is similar to the builder notation, also proposed for Java 7 (new X().setProp1().setProp2() where the props return void) and is meant to combine the two proposals. The same as the builder proposal; the value of the second statement above is list1.addAll( list3 ). Different than the builder proposal; the intermediate values, e.g. list1.addAll( list2 ), are always discarded.

Stephen Colebourne has suggested something similar but proposed .do. instead of -> and didn’t include the original argument getting passed to all the methods, i.e in the second example above list1 is given to both addAlls.

I do believe that it is possible to implement traits. I just don’t think it would be a good idea to implement traits, because I’m concerned about compatibility and I like mixins better

Your examples break at least source compatibility.