481–490 of 557 posts
> “I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” —Alan Kay.
Read here for more info: http://xahlee.info/comp/Alan_Kay_on_object_oriented_programi...
Earlier quoted context omitted.
> The Square vs Rectangle issue is just an example. Yes, it's an example of a problem that has nothing to do with OOP and everything to do with applying model concepts from one domain to a different domain. > They shouldn't even be modeled as a hierarchy they should just be simple structs. Whether they are structs or objects with state and attached methods is an orthogonal concern to whether they form a type heirarch…
We will just have to agree to disagree then, for me the Square vs Rectangle inheritance issue is the simplest possible example of the problem, where trying to model an inheritance hierarchy "the right way" directly impacts the structure of your code in a detrimental way, and the solution is to avoid OOP silliness in its entirety. Even in the immutable case if you have a Square inherit from Rectangle it still stores 2…
Can't tell if this is deliberately ironic...
Earlier quoted context omitted.
If the square and rectangles are not mutable, you can indeed treat a square as a rectangle (however you want to express that type). If they are mutable, then a square is of course not a rectangle. In OOP systems that support predicate-style dynamic inheritance, rectangles pick up the square trait only when their width is equal to their height. We don't talk about such systems very much today (JavaScript does not have…
Pretty cool to hear about those, didn't know there was such a dynamic approach to the problem. Either way, the problem in my view is that the question is silly to begin with, Squares and Rectangles should be PODs (or, even better, simple structures), and not have any associated behavior. The decision of whether they are mutable or not then depends solely on the needs of the software, and not on irrelevant modelling c…
Earlier quoted context omitted.
We will just have to agree to disagree then, for me the Square vs Rectangle inheritance issue is the simplest possible example of the problem, where trying to model an inheritance hierarchy "the right way" directly impacts the structure of your code in a detrimental way, and the solution is to avoid OOP silliness in its entirety. Even in the immutable case if you have a Square inherit from Rectangle it still stores 2…
You are building a straw man from your misunderstanding of the OOP technique. As 'dragonwriter' tried to explain it to you that mathematical model of a square being a kind of a rectangle has nothing to do with OOP modeling. Liskov substitution principle tells you that a rectangle cannot be a super class of a square.
I think this generalizes to any "this is a more constrained that".
Earlier quoted context omitted.
If only we could completely eliminate state! Thankfully, I am working on a plan for this. It should take around 10^106 years... give or take. The serious comment here is that the real world imposes a minimum floor on the amount of mutable state that you have to model. Databases are giant piles of mutable state. Maybe we should start talking about "essential state" and "accidental state" the way we talk about complexi…
I agree and would add that the UI is also a pile of mutable state. Even if you model the DOM using a pure function, there's still scroll position, selection, animation, history, and so on. At the end of the day, users interact with state. We need languages and techniques that manage it well.
That's because what people call OOP isn't OOP. > “I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.” —Alan Kay. Read here for more info: http://xahlee.info/comp/Alan_Kay_on_object_oriented_programi...
Earlier quoted context omitted.
The second one scares me. It implies some_state is mutated (or not, we may just be logging something) by the do_stuff function while the first makes it very clear that some_state is in charge of doing stuff and that the implementation is aware of how some_state is implemented itself. OTOH, the second one would be much better (and imply immutability) if it were written as new_state = do_stuff(some_state) But it'd also…
This is a symtom of seeing everything with the OOP and state glasses. let's have do_stuff=square and some_state=2. What does square(2) imply?
Earlier quoted context omitted.
Games are actually moving away from OOP by separating out state into a data oriented system.
But aren't they doing that mostly for performance via better memory layout and thus better cache locality? ie: arrays of objects vs objects of arrays. It's a sacrifice of code architecture for performance. I feel like games are actually a good example where OOP makes sense, since there is inherently so much state and encapsulation is useful.
Earlier quoted context omitted.
> This sort of begs the question: where does classical OOP, the one taught to all undergrad CS majors in programs that use Java or C++, really fit in nowadays? I have no idea. The smalltalk ideal of OOP lives on in all sorts of ways, but the deep inheritance chain version that gets taught in classes? I don't think it has a place apart from maintaining existing code.
> The smalltalk ideal of OOP lives on in all sorts of ways, but the deep inheritance chain version that gets taught in classes? What is the deepest chain we find in SmallTalk itself? I can't check it right now, but I'm sure it's not as deep as some classroom examples I've seen. Inheritance makes a lot of sense when you are modelling the world, but most structures we see in the real world aren't that deep.