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

[Tim Peierls]

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<T> implements Block<T>, Sink<T> {
>       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<Foo> 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