Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces (original) (raw)
Brian Goetz brian.goetz at oracle.com
Wed Nov 14 11:17:21 PST 2012
- Previous message: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces
- Next message: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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"?
If not, why are these distinguished interfaces (which are regular interfaces, so people could implement them in named or anonymous classes too) not getting the same flexibility?
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.
This is so bad that we want to ensure that it NEVER EVER HAPPENS?
On 11/14/2012 12:29 PM, Tim Peierls wrote:
Implementing more than one of the functional interfaces sounds like a bad idea; making it difficult or impossible to do is a *good *thing. Use apply everywhere to prevent things like Shimmer implements FloorWax, DessertTopping.
Does anyone have any compelling example of why you actually might want to implement multiple functional interfaces that isn't satisfied by using asFunction, asPredicate, asProcedure, etc. methods? --tim On Wed, Nov 14, 2012 at 12:12 PM, Mike Duigou <mike.duigou at oracle.com_ _<mailto:mike.duigou at oracle.com>> wrote: The issue is primarily when one class wants to implement more than one functional interface. If the names collide then the class will only be able to implement one of the interfaces. Mike On Nov 14 2012, at 07:12 , Craig P. Motlin wrote:
What's the issue with both methods being named apply?
On Tue, Nov 13, 2012 at 2:05 PM, Mike Duigou <mike.duigou at oracle.com <mailto:mike.duigou at oracle.com>> wrote: The name Block.apply currently conflicts with Function.apply and should be renamed.
- Previous message: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces
- Next message: Request for Review (#2) : CR#8001634 : Initial set of lambda functional interfaces
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the lambda-libs-spec-observers mailing list