2016-05-15 16:21 GMT+02:00 Rasmus Schultz <ras...@mindplay.dk>: > > As a downside, you can't implement it in a normal class anymore and just > use > > an instance of that class. > > I see that as a plus, because, as a you said: > > > That's why you call it with the method name of the interface > > Your logic is circular - you also said: > > > As a downside, you can't implement it in a normal class anymore and just > use > > an instance of that class. > > So you want it both ways, class and callable. > > But if I'm not supposed to invoke it as a callable, why implement it > as a callable in the first place? > > In other words, you can't really have both - it doesn't really work: a > callable can be treated as a class, but a class can't be treated as > callable. If I have to treat everything as classes anyhow, why not > just use classes? > > The only advantage seems to be shorter syntax than anonymous class > declarations - the resulting objects have to be treated the same way > in practice,
>From the RFC: The anonymous class version: - must use referencing, or fetch a new Countable object on each iteration, - is extremely verbose - must set dependencies in the constructor - has no support for lexical scope The functional interface version: - is sparse - is easier to reason about - does not require the use of references - supports lexical scope - Functional interface support does not change the definition of an interface, and only reuse the definition of a Closure. > e.g. you can't safely treat them as callables. That's > where the chain falls off for me: you end up with callables, but you > shouldn't depend on them being callables, so then why make them > callables in the first place?
