3 ms·
Nice article, but I don’t fully understand why the author argues for such an aversion to static functions. > Moreover, it breaks the systematic approach of sen
by msdz 2mo ago
Nice article, but I don’t fully understand why the author argues for such an aversion to static functions.
> Moreover, it breaks the systematic approach of sending messages to an instance (often presented as one of the key arguments in favor of object-oriented programming).
Is this just a matter of “the code will become spaghetti once too many classes/methods/implementations exist”? And, conversely, is a non-static method with a constrained, i.e. somehow different type (or also the approach of moving a method outside of the class proper) not more confusing?
- psd1 2mo agoI'm learning F#, not sure if this generalises to ocaml too. In F#, there is no function overloading, but there is method overloading. F# lacks higher-kinded types, but it's possible to roll your own using techniques from the article. https://robkuz.github.io/Higher-kinded-types-in-fsharp-Intro-Part-I/ https://robkuz.github.io/Higher-kinded-types-in-fsharp-Intro... https://github.com/G-Research/TypeEquality https://github.com/G-Research/TypeEquality This gets you a bit closer to the power of Haskell. It's code golf - f# community consensus is to prefer simple explicit code. But it avoids runtime type checks, so can be a performance optimisation.