3 ms·

I'm not sure how this is anymore inefficient than what a functional design would come up with. Is asking the objects about their behavior any more inefficient t

I'm not sure how this is anymore inefficient than what a functional design would come up with. Is asking the objects about their behavior any more inefficient than dispatching yourself based on the characteristics of that object? > What was the benefit of the exercise? I don't know, you were the one that asked about it. What was your point? > first there's the fact that it's the Integer class that implements readFrom (and that class has no internal data beyond its type, so it's just a namespace) Ah, but it's the _trait_ that would implement that behavior (my original post said that classes are just an over-simplified way to look at object programming, and I stand by that. I'm working within a prototype-based framework). So the integer's behavior would be provided by the trait, as well as the behavior to create it. > and the fact that in order to create the integer, the class has to see the data that comes out of the stream I'm not sure how that goes against what I said? Indeed it would. > If you think this is object-oriented I have a bridge to sell you. You can have non-object programming style bits in an object programming language. I'm not even sure what your original point was if this is what you're saying: that an object programming environment contains procedural or functional styled bits? I don't disagree with that, but a functional-style programming language will contain object programming-style bits just the same.

sirwhinesalot 3y ago
My apologies if I wasn't clear, my point is only the full blown object oriented style of programming (meaning one where everything in the program is modeled as an own entity with its own state that responds as it wishes to a set of messages) is silly. The "everything is an object" idea. Objects with no associated behavior or state aren't objects, *by definition*, and there's plenty of code out there that benefits from data with no associated behavior and behavior with no associated data. This happens even in true OO languages like smalltalk. Attempting to model everything as "objects" (read: own private state + behavior) not only may have performance implications due to poor cache usage and multiple indirections, it also makes modelling certain concepts harder (see: object-relational mismatch). The example I gave is a clear example of the latter, since it is very much a relational problem. (Eric Lippert has some very good articles on the matter). That's not to say objects aren't valuable (they appear as a pattern even in functional languages) nor that "live" software isn't a great idea. Personally I think a lot of software would benefit from extensibility, which means plugins at least, which in turn means objects (private state + responding to a set of messages as they wish)

sirwhinesalot 3y ago

My apologies if I wasn't clear, my point is only the full blown object oriented style of programming (meaning one where everything in the program is modeled as an own entity with its own state that responds as it wishes to a set of messages) is silly. The "everything is an object" idea. Objects with no associated behavior or state aren't objects, *by definition*, and there's plenty of code out there that benefits from data with no associated behavior and behavior with no associated data. This happens even in true OO languages like smalltalk. Attempting to model everything as "objects" (read: own private state + behavior) not only may have performance implications due to poor cache usage and multiple indirections, it also makes modelling certain concepts harder (see: object-relational mismatch). The example I gave is a clear example of the latter, since it is very much a relational problem. (Eric Lippert has some very good articles on the matter). That's not to say objects aren't valuable (they appear as a pattern even in functional languages) nor that "live" software isn't a great idea. Personally I think a lot of software would benefit from extensibility, which means plugins at least, which in turn means objects (private state + responding to a set of messages as they wish)