4 ms·
Why? You would never suggest this if OO wasn’t the predominant paradigm. What is the benefit of implicitly passing the parameter? I prefer to see it passed expl
by amw-zero 6y ago
Why? You would never suggest this if OO wasn’t the predominant paradigm. What is the benefit of implicitly passing the parameter? I prefer to see it passed explicitly, so the implicit passing is a downside to me, not a benefit.
- hamandcheese 6y agoThe benefit is encapsulation.
- _0ffh 6y agoDon't need a dedicated OOP lang for that benefit. It's an age-old discussion. As old school software engineering became sufficiently advanced, some people bundled their favorite "state of the art" concepts, and called it OOP. (Also: Multiple people, multiple different concepts of what "OOP" actually precisely means.) It became a horrible hype, and from then on out everyone was taught to see all these concepts as "OOP concepts" that elevate OOP over other programming paradigms. But they're not and they don't. The only real "advantage" is, OOP languages are opinionated and will try to force their interpretation of these concepts on the coder. Which is nice, if you happen to like it that way. Just not everybody does.
- fnord123 6y agoEncapsulation's a weird one. It's a cornerstone of OO but most/all OO languages have rubbish support for ABIs so changing your object in one library means you need to recompile your code using the library. This is the opposite situation that encapsulation seems to promise (in my view).
- thom 6y agoIs encapsulation different in either case? Nobody should be operating directly on the state, any more than they should be reflecting on private fields in a class.
- fauigerzigerk 6y agoThe canonical answer is encapsulation. But in my view it's rarely a good idea to couple state related to an algorithm's invocation (e.g a cache) with the data structure itself.
- noobermin 6y agoIt's almost as if a hard and fast rule doesn't work, ie., the point of the article.
- jabirali 6y agoIn many languages, it is an explicit parameter though. For instance, in Python, one would define a function with `def fun(state)` or a class method with `def fun(self)`. In the function body, one would use respectively `state.var` or `self.var` to refer to a variable `var` in the state object. Running it is then done using `fun(state)` or `state.fun()`. There are some minor syntactic differences between the two, but I find both these examples to be just as explicit...
- still_grokking 6y agoSo you would not use type-classes in Haskell as they rely on implicitly passed parameters to functions?
- kqr 6y agoI can't speak for the GP, but what makes typeclasses in Haskell work for me is that there's a very strong cultural force ensuring that they are truly about consistency boundaries and maintaining invariants/laws. Haskell developers don't just create a typeclass to bunch related functionality together. Doing so is a common beginner's anti-pattern. Typeclasses exist to wrap up general operations that satisfy some laws. When objects in OOP are used in the same way, I don't mind it as much. It's when they're not that I don't find the syntactic inconvenience worth it.
- js8 6y agoIn Haskell typeclasses, it's the type of the parameter that is implicitly passed, not the parameter itself.
- uryga 6y agoi don't think that's correct, afaik typeclasses roughly desugar to passing a record of functions (vtable/"dictionary") at the call site
- taejo 6y agoAnd that vtable depends on the type, not the value.
- uryga 6y agoi guess there's really two implicit arguments - the value's type, `a` (quantified via forall - the System F "Λ") and its vtable `Show a`... though i guess the vtable is uniquely determined by the type bc in Haskell instances are globally unique
- mcv 6y agoIf it's already explicitly part of an object, do you need to be explicit about the same thing twice?