3 ms·

But...that was exactly the question the article had. Should drum be the enclosing class, or should stick be? What he cares about is the verb play, but he has to

But...that was exactly the question the article had. Should drum be the enclosing class, or should stick be? What he cares about is the verb play, but he has to encapsulate it in a noun, and none of the ones actually involved dominate so clearly as to moot having to make a choice.

nine_k 5y ago
musicPart.play(drum, sticks); Basicslly you can replace the module namespace with a class namespace if desired. What module could that be?
- ReleaseCandidat 5y ago
  But now the traits aren't connected with drums (or sticks) but MusicParts. Or you end up having some `drum.foo` too.
  - deleted 5y ago
    [deleted]
- lostcolony 5y ago
  Right. But that's just it. "musicPart" is an object. A noun. What the hell is a "Music Part"? It's a completely synthetic object you've had to create solely to namespace functions. It's like how so many large Java projects have static "Utils" classes. What you've done is not OO; in fact, it's an anti-pattern in OO. You've created, as you correctly note, a namespace or module around static functions; there is no meaningful encapsulation of data. My point isn't that it can't be done, it's that trying to follow best OO practices, you run into this sort of problem (which has had a lot of digital ink spilled on it). The fact there is a pragmatic solution isn't in any doubt; it's that such a solution intentionally eschews the data encapsulation that OO demands (but not imperative or functional approaches, which instead say it's the right approach to do that).
  - nine_k 5y ago
    If you ever played music, you know it consists of parts. Say, a percussion part, a bass part, a rhythm guitar part, a lead guitar part, a vocal part, etc.
    - lostcolony 5y ago
      Why would 'play' hang off of the (presumably static) "MusicPart" then, rather than, "Player", "Musician", "Composition", etc? Also, you realize that this whole discussion is proving the point, right?

nine_k 5y ago

musicPart.play(drum, sticks); Basicslly you can replace the module namespace with a class namespace if desired. What module could that be?

ReleaseCandidat 5y ago
But now the traits aren't connected with drums (or sticks) but MusicParts. Or you end up having some `drum.foo` too.
- deleted 5y ago
  [deleted]
lostcolony 5y ago
Right. But that's just it. "musicPart" is an object. A noun. What the hell is a "Music Part"? It's a completely synthetic object you've had to create solely to namespace functions. It's like how so many large Java projects have static "Utils" classes. What you've done is not OO; in fact, it's an anti-pattern in OO. You've created, as you correctly note, a namespace or module around static functions; there is no meaningful encapsulation of data. My point isn't that it can't be done, it's that trying to follow best OO practices, you run into this sort of problem (which has had a lot of digital ink spilled on it). The fact there is a pragmatic solution isn't in any doubt; it's that such a solution intentionally eschews the data encapsulation that OO demands (but not imperative or functional approaches, which instead say it's the right approach to do that).
- nine_k 5y ago
  If you ever played music, you know it consists of parts. Say, a percussion part, a bass part, a rhythm guitar part, a lead guitar part, a vocal part, etc.
  - lostcolony 5y ago
    Why would 'play' hang off of the (presumably static) "MusicPart" then, rather than, "Player", "Musician", "Composition", etc? Also, you realize that this whole discussion is proving the point, right?