|
|
|
|
|
|
by gfxgirl
2207 days ago
|
|
|
Maybe I'm mis-understanding the definition of class or object but isn't a "File" in even Haskell an example of a class. Files have state which is either the read head or write head and in most languages you can change the head using seek. I don't think the fact that you call `file.seek` vs `seek(file)` the difference between functional and object oriented. functional people say "state = evil, side effects = evil" and yet that version of `seek` has both. The functional version of files would have to move the head out of the file newWritePosition = write(file, currrentWritePosition) And there would be no need for seek since you're holding your own write and/or read position. If you close over a bunch of state and pass back a function or functions to work with that closed state you've just created an object with state and side effects. That's exactly what FP people say is bad. |
|
|
- Subclassing is notoriously misleading and confusing and almost never truly useful (true subclassing, not abstract subclassing/interfaces).
- Class syntax/semantics are usually divorced from the other semantics of the language; closures are usually a much simpler design to achieve the same power. (You can get class-like ideas with simpler ideas too, but I think most “class” features don’t.)
- Culturally, classes are often viewed as mythic/special in a way that’s kind of out of touch with mapping problems to solutions. Look at “typical” Java code full of classes for crazy tasks like implementing 20 getters and constructing a factory to create callbacks. All of these things are related to the problem, but there’s a lot of friction/mismatch because people are taught to “use classes.”