Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces (original) (raw)

Tim Peierls tim at peierls.net
Wed Nov 14 11:42:07 PST 2012

On Wed, Nov 14, 2012 at 2:17 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

Take this query to its logical conclusion. Would you have argued that the method name for Runnable, Callable, or Comparator should have been something devoid of information like "method" or "invoke"?

I don't think that having them named differently has been particularly useful. But I'm not trying to make a general case here. I'm just thinking about the "functional" types that appear in the signatures of the new lambda-libs stuff.

As an example, Doug has pointed out the risk that library A will call its

"handle one element" type "Block" and another will call it "Sink", and one might have void return and one might be more like "Collection.add" where it returns boolean. and clients will be endlessly converting their blocks and sinks back and forth, inviting inefficiency and churn. But if a client wants to create a class that acts as a receiver from things produced by both libraries, they can just implement both:

class ElementReceiver implements Block, Sink { void theBlockMethod(T t) { doSomething(t); } boolean theSinkMethod(T t) { doSomething(t); return something; } } Then they can say: ElementReceiver e = new ElementReceiver(); libraryA.**registerElementHandler(e); libraryB.onElement(e); and be happy.

I'd rather see:

import static ......toBlock; import static ......toSink;

ElementReceiver e = new ElementReceiver<>(); libraryA.**registerElementHandler(toBlock(e)); libraryB.onElement(toSink(e));

and avoid coupling ElementReceiver to either library.

This is so bad that we want to ensure that it NEVER EVER HAPPENS?

No, but bad enough to make me prefer a single method name to interface-specific method names.

--tim

More information about the lambda-libs-spec-observers mailing list