3 ms·
This is a case of employing OO to circumvent a problem in OO languages. There's two potential problems with if statements: 1) non-locality 2) fragility. 1) can
by moomin 10y ago
This is a case of employing OO to circumvent a problem in OO languages. There's two potential problems with if statements: 1) non-locality 2) fragility.
1) can often be dealt with by changing the code, or parameterising. But in general, you want to be able to specify your own interface and specify how specific classes handle it. The article misses out one important detail, because the average OO language doesn't handle it: you might want to do this to someone else's class
2) You can make fragile code in any language, but the absence of pattern matching with totality checking makes it much worse.
Of course, there's a third problem that's implicit throughout the article: the inability to verify something's not null through the type checker.
The ideas in the article are good, but they're patterns for circumventing problems in your programming language. There's languages with no OO whatsoever that avoid the problems.
- b0bdog 10y agoCare to go into some details/examples of your last sentence?
- moomin 10y agoI think this article is a pretty good introduction to when exhaustive pattern matching is desirable: http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipattern.html http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt...
- millstone 10y agoThe problem identified has nothing to do with OO. Look at this code: logFile.write(message); We might as well replace `logFile.write` with `fprintf(logFile...)`, and get the same result in C. So we don't need OO to experience this pain. Conversely, this is only a "problem" if `logFile.write()` results in SIGSEGV or NullPointerException or whatever. But some OO languages (Smalltalk, Objective-C, others?) dodge this by making null a message black hole. Confusing, but terribly convenient. One last point: notions of "pattern matching with totality checking" or "verify something's not null through the type system" presupposes exhaustive knowledge of the environment in which your code will run. Maybe that's correct: google.exe on Google owned hardware in Google-owned data centers will behave very precisely. But sometimes it's not correct. Your JavaScript code is running in a yet-to-be-written browser on an ancient version of some OS on random hardware. Your code's typechecking environment is unrelated to its runtime environment. Totality checking requires predicting the future. In this highly dynamic universe, languages like Haskell have no good solutions.
- moomin 10y agoYou're right, you could certainly experience the pain in a non-OO language that silently allows invalid values to creep through the system. However, it's an error _every_ OO language makes. Smalltalk, Objective-C and Clojure dodge it, but they don't dodge it for long: the nulls can now propagate further through your program, making it harder to track your problem down. I'm not sure your last point buys us anything. I mean, any runtime environment can have bugs, and any future system can have cases you haven't handled. This will break your OO code just as fast as pattern-matching. Because OO dispatch is really just a special case of more general mechanisms. Have a chat to some purescript guys about when they have trouble with JavaScript nulls. I bet the answer is "when we interface with raw JavaScript code and don't define our types correctly".