241–250 of 255 posts
Earlier quoted context omitted.
There are at least a few ways to define and implement interfaces in C++ without touching inheritance.
Structures of function pointers and, what, string method names? My C++ is rusty, but that's all I can think of. I guess there's a lot of variations on structures of pointers...
Earlier quoted context omitted.
> The thing that ends up breaking in the squares and rectangles examples is mutability. Mutability isn't sufficient. Breakage requires more than mutability. In dynamic languages, a mutated object can retract its squareness (smalltalk `become`; javascript __proto__ assignment; python object self-mutation). And predicate types (it's a Square iff its sides are the same length) are even graceful. So I'd rephrase that as…
Good point. I would expect the immutable version of scaling a side to return a new rectangle, thus allowing a scaled square to also return a rectangle. I hadn't thought about mechanisms that would allow a type to basically upcast itself in a mutable operation. Of course, for typing proposes, the signature looks the same: This operation yields a rectangle. It's really just a matter of where the return value lives.
Well, it yields a type union of square and rectangle. A runtime, whether the original language appears mutable or not, can play games with that. Like resolving types lazily. If for example some object is only drawn, and draw happens to dispatch it independently of squareness, on say a predicate type DistantObjectThatLooksLikeADot, then there's no need to resolve whether it was square. No one will ever know. Or ever have to pay the cost of finding out. It has say a MightBeSquareMightBeRectangleHaventHadToCareYet dictionary. :) Which can become important as types get more expressive, and expensive to prove/test.
If you ever open the hood of a modern car and look around a bit you'll discover that at the front there's a half dozen pullies connected to one or more belts. Each of these pullies is connected to some diffeerent system each able to turn rotational acceleration into a useful service. The alternator converts that rotational energy into electricity. The AC unit uses it to operate a heat pump. The coolant and oil pumps…
You’ve described interfaces, not so much inheritance.
If you ever open the hood of a modern car and look around a bit you'll discover that at the front there's a half dozen pullies connected to one or more belts. Each of these pullies is connected to some diffeerent system each able to turn rotational acceleration into a useful service. The alternator converts that rotational energy into electricity. The AC unit uses it to operate a heat pump. The coolant and oil pumps…
Which is also why these modern cars have turned a minor belt failure into an expensive catastrophic failure, often destroying much of the engine. I'd hardly call it a design to aspire to. I'd probably compare it more closely with a system where everything receives a mutable God object.
Earlier quoted context omitted.
Agreed. In fact I would expect the Square subclass to implement width= and height= so that they each actually set both internal values.
So this behavior is reasonable? Rectangle r=getRectangle(); r.width=1; Assert(1, r.width); //passes r.height=2; Assert(1, r.width); //fails or passes depending on subclass
I believe the right choice is to have an AbstractRectangle class representing the rectangle with any further constraints and Rectangle class representing the rectangle with no further constraints.
Earlier quoted context omitted.
Structures of function pointers and, what, string method names? My C++ is rusty, but that's all I can think of. I guess there's a lot of variations on structures of pointers...
In Sean Parent's 'Inheritance is the base class of evil' talk Sean outlines an interesting way to achieve runtime polymorphism without inheriting interfaces in C++. https://www.youtube.com/watch?v=bIhUE5uUFOA
You see it at 9:44. Where he creates the concept_t and int_model_t inherits from it.
Earlier quoted context omitted.
Which is also why these modern cars have turned a minor belt failure into an expensive catastrophic failure, often destroying much of the engine. I'd hardly call it a design to aspire to. I'd probably compare it more closely with a system where everything receives a mutable God object.
But modern cars don't need nearly as much maintenance and are more reliable on averable.
My 91 pickup and 99 minivan's engines are still going strong with well over 200k miles, rarely having anything major wrong with them in the entire time I own them, whereas my 2004 and 2009 cars both with ~100k miles have been nothing but total maintenance nightmares. Timing issues, computer failures. Sheer nightmares.
Earlier quoted context omitted.
Good point. I would expect the immutable version of scaling a side to return a new rectangle, thus allowing a scaled square to also return a rectangle. I hadn't thought about mechanisms that would allow a type to basically upcast itself in a mutable operation. Of course, for typing proposes, the signature looks the same: This operation yields a rectangle. It's really just a matter of where the return value lives.
> for typing proposes, the signature looks the same: This operation yields a rectangle. It's really just a matter of where the return value lives. Well, it yields a type union of square and rectangle. A runtime, whether the original language appears mutable or not, can play games with that. Like resolving types lazily. If for example some object is only drawn, and draw happens to dispatch it independently of squarene…
How do languages with sum types handle scenarios where the type is A+B, but B is a subtype of A? So you're really guaranteed to have an A, but you may or may not have a B? Do they allow transparent reference as type A, or must you disambiguate first?
That is, given a function that takes an A, can you pass it a type A+B, given that B is a subtype of A?
Earlier quoted context omitted.
Will a bicycle? A plane? A boat?
Most of them. But that's not the point. Not all subtypes are applicable to any task in OOP either.