4 ms·

I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes. The way lambdas bind to SAM interfaces and implement

I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes. The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly. I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.

kaba0 4y ago
I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.
- kjeetgill 4y ago
  > I’m not sure whether you mean semantically or in implementation I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough. > rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to. I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound. We can get along! There's no need for this feud!
  - kaba0 4y ago
    I just wanted to add something I knew on the topic, but you seem to know much more! Thanks for the interesting read, and it is indeed a cool duality!

kaba0 4y ago

I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.

kjeetgill 4y ago
> I’m not sure whether you mean semantically or in implementation I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough. > rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to. I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound. We can get along! There's no need for this feud!
- kaba0 4y ago
  I just wanted to add something I knew on the topic, but you seem to know much more! Thanks for the interesting read, and it is indeed a cool duality!