@Crell they are extensively used in C# too, I can see how they're useful but I can't get myself to like them, it feels hacky, like adding a method to a class prototype in JavaScript.
@maxalmonte14 Where I'm seeing them in Kotlin is for converting objects of type A to type B. That code often makes little sense "in" either class, but extension functions let it live externally without a whole new class hierarchy to think about.
@Crell@maxalmonte14 I currently write TypeScript and I really miss extension functions too. Especially since the JS standard library is so thin. And map.groupBy(...) is so much nicer than Map.groupBy(map, ...).
And as for hacking the prototype, the big difference is that you explicitly import extension functions when use them. So it is not forced upon anyone else, and the world does not break if someone else creates an extension function with the same name.
@henrikjernevad@maxalmonte14 The alternative is Elixir-style pipes, which auto-close for multiparameter functions. I quite like it, but that's probably even less familiar for a lot of people.
@Crell@maxalmonte14 I agree. And I think several languages has shown that the last few years. From the ones I am familiar with, Scala was a surprisingly successful FP/OOP hybrid experiment. Then Kotlin took "the best parts to the masses". But even Java and C# has moved a lot towards FP. And JavaScript is flexible and weird enough to fit both camps.
@henrikjernevad@maxalmonte14 Most of the guidelines for "good" OOP are borrowed straight from FP, with or without some twisting. Honestly a structurally typed language (Go or Rust) could, with the proper features, easily straddle both sides perfectly.
Add comment