Ugh!

I think that all future requests for changes to the language should be
accompanied by an irrevocable guarantee from the requester that he, she, or
they, would do the actual work of updating /all/ the tools that would be
affected by the change.  I.e. they would do the work of updating javac, they
would do the work of updating Eclipse, they would do the work of updating all
the hundreds of other tools out there which parse Java.

Beyond that, if you /are/ going to mess around with Java to support that idiom,
it would be /much/ better to support it properly.  There is nothing to stop you
defining a syntax that means "send this message to the receiver of the previous
message".  A parallel in Java of Smalltalk's "cascades" rather than the hacky,
restricted, and ugly "chaining" idiom.

   -- chris

Many methods return values that programmers are unaware of. For
instance, remove methods may return a boolean to indicate something or
to return a previous value. That's going to make code using your
suggestion fail unexpectedly. Or in some case do things on an unexpected
object.

I don't like your chances of getting anything like this through. If
something were going to be introduced, I'd hope it'd go for a more
distinctive syntax, say:

    builder ->
        append("This "),
        append(stuff),
        append(".");

Tom Hawtin

Thank you all for your responses.