3 ms·
Didn't the author address that? > In effect, the major selling point of the “object”-style design here is also a major downside: you don't have guarantees abou
by GavinMcG 6y ago
Didn't the author address that?
> In effect, the major selling point of the “object”-style design here is also a major downside: you don't have guarantees about the specific representation of data, which means your programs can easily mix-and-match different representations, but it also means that your program can't make use of representation-specific knowledge in ways that are advantageous.
> There's another major concern as well, and that's that the specific choice of “object” representation can make a big difference in terms of what operations you can and cannot support.
- Geminidog 6y agoThe author is talking about representation of data, I'm talking about something different. I'm talking about scoping, grouping, modularity and free variables. y = 6 f(x) = x + y y is called a free variable and f is dependent on it. I cannot move f to another place because y will now be undefined. OOP is a more extreme version of this. class X y = 6 b = 8 f(x) = x + y Now f can't even be moved to another place without b. If you want to move f you have to move b as well. Combinators vs. free variables is the fundamental issue of OOP which this article writer effectively side steps with a unique definition of OOP where the method returns an entirely new object with differently defined methods. It's ok. It's worth talking about the trade offs of unique definitions of OOP but I think the author needs to mention that this is also not a mainstream definition and therefore sidesteps all the mainstream controversy.