3 ms·

The thing is that OO forces taxonomy on you, especially if you have to deal with lots of inheritance.

taeric 3y ago
It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.
- coldtea 3y ago
  >Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
  - taeric 3y ago
    I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
    - coldtea 3y ago
      >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
      - taeric 3y ago
        OO with minimal hierarchies is basically leaning into metaphor for modeling techniques. It is akin to how a large number of informal models have worked for a long time. If you are focused on just the code organization side of the implementation, I can mostly agree with that. Even if I have grown fond of Java's much more predictable nature on where to find things. Modules or any other organization would have probably been fine.

It doesn't have to, though, if you are willing to not try and encode the world. Type systems, in general, seem to hit the same problem. If not, why? Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. You can have prescriptive interfaces that say what all has to happen for some work, but that should be much tighter in how it is put together.

coldtea 3y ago
>Keep the hierarchies shallow and be willing to go with descriptive definitions over prescriptive ones, and I think things can work out some. In that case you're just doing encapsulation with extra steps.
- taeric 3y ago
  I'm not sure I follow? Any chance I can get you to expand on that? By descriptive, I'm less worried about hiding things. Though, yes, that is certainly a hallmark of how people talk about OO. I mainly don't like getting into debates about where in an inheritance tree something would go. Even if I do think there are values in small hierarchies. The most bang for buck is when they help someone implement a new part of the system. The last bang for the buck is when you are doing a lot of coding just to keep an inheritance tree looking a certain way.
  - coldtea 3y ago
    >I'm not sure I follow? Any chance I can get you to expand on that? I mean, if you're trying to avoid hierarchies or keeping them small (like, say 2 levels most), then what are you using from the OO paradigm, except using classes as some kind of a bundle for related methods and for encapsulation? I'm not saying hierarchies are good or OO is good. Just that OO-while-avoiding-hierarchies doesn't seem worth to be a paradigm. Might as well ditch OO altogether, there are other ways to get the things you're keeping from OO then (e.g. Rust or Go style).
    - taeric 3y ago
      OO with minimal hierarchies is basically leaning into metaphor for modeling techniques. It is akin to how a large number of informal models have worked for a long time. If you are focused on just the code organization side of the implementation, I can mostly agree with that. Even if I have grown fond of Java's much more predictable nature on where to find things. Modules or any other organization would have probably been fine.