First up a quick critique of the proposals.

Extension Methods

The idea is that if you use a static import then you can call an imported static method using the dot notation used currently for instance methods, e.g.:

    import static java.util.Collections.*;

    ...

    list.sort();

Whereas currently you would have to write:

    sort( list );

It is certainly nice that using the proposal you gain some readability because methods read left to right, for example consider chaining methods:

    list.synchronizedList().sort();

Which reads better than:

    sort( synchronizedList( list ) );

On the downside the proposal implies that sort is part of List and that it is dynamically dispatched. But suppose you wanted a different sort that was more optimum for a ConcurrentLinkedQueue, that was also statically imported:

    import static java.util.Collections.*;
    import static MySortMethod.*; // Includes a sort method for ConcurrentLinkedQueue

    ...
  
    List list = new ConcurrentLinkedQueue();
    list.sort();

There are two sort methods, one associated with List and one with ConcurrentLinkedQueue. With normal dynamic dispatch, as implied by the dot notation, you would expect sort( ConcurrentLinkedQueue ) to be called. But it won't be; because the dispatch is static, therefore sort( List ) is called.

Chained Invocation

This second proposal is that if a method returns void it is assumed to return its own receiver (similar to returning this but retaining the type of the receiver which might be a sub-type of this), e.g.:

    list.add( 1, "A" ).add( 2, "B" );

Currently you would write:

    list.add( 1, "A" );
    list.add( 2, "B" );

The proposal certainly reduces repetition. But it has a limited use case, e.g. add( int, Object ) returns void but add( Object ) returns boolean and therefore can't be used.

One of the main use cases for this proposal is the Builder pattern in conjunction with settable properties, e.g.:

    Home home = new Builder().setWindows( windows ).setDoors( doors ).makeHome();

I will come back to this builder example below, the key point is that the result of makeHome is a Home not a Builder.

With Clause

I would like to propose a superior alternative to both the above proposals. Pascal and other languages have a with construct that saves repeating the receiver of the call. Similarly a with construct but using an operator could be added to Java. The examples given above for both Extension Methods and Chained Invocation can be expressed as a with clause thus demonstrating that both proposals can be unified.

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

The -> operator supplies the first argument to any method. For instance methods the first argument is the receiver (hidden this). If -> is applied to a block then the object on the left of -> is supplied to all the methods and the value of -> is the value of the last method (values from intermediate methods are discarded).

Using a different operator, ->, has the advantage of not implying dynamic dispatch and since the feature works with all methods: instance methods, statically imported functions, and non-statically imported functions it has a wide use case.

What do fellow Artima's think; are Extension Methods, Chained Invocations, or with clauses worth adding?

list -> sort();

sort(list);

list |. sort(); // in your syntax: list -> sort()
list|.sort(); // looks more like list.sort() (i.e. normal method invocation
list |. Collections.sort(); // 'pipe' it to Collections#sort(List)
list |.synchronizedList() |.sort();

    list->synchronizedList()->sort();
    int index = list->{ sort(); binarySearch( key ); };
    list.{ add( 1, "A" ); add( 2, "B" ); };
    Home home = new Builder().{ setWindows( windows ); setDoors( doors ); makeHome(); };

list -> filter( test1 ) -> filter( test2 ) -> sort();

sort( filter( filter( list, test1 ), test2 ) );