Summary
Two Java 7 proposed extensions, extension methods and chained invocations, give extra meaning to method call syntax. Neither proposal has proved popular with bloggers and this blog suggests an alternative.

---

Advertisement

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?

Talk Back!

Have an opinion? Readers have already posted 16 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Howard Lovatt adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Dr. Howard Lovatt is a senior scientist with CSIRO, an Australian government owned research organization, and is the creator of the Pattern Enforcing Compiler (PEC) for Java. PEC is an extended Java compiler that allows Software Design Patterns to be declared and hence checked by the compiler. PEC forms the basis of Howard's 2nd PhD, his first concerned the design of Switched Reluctance Motors.