Hacker News Reader

I always find that the common example of Rectangles and Squares leads me to a different conclusion. It assume that the best way to go about is to only have a single sideLength method, but from a data structure perspective it seems more obvious that the Squares class substitute instead the validation method by adding constraints that a valid square only exist when both sides are equal. Rectangle class must already have a validation method that check that each side is greater than zero, so it seem like the obvious place to define a square. Any additional methods or properties like sideLength would just be added convenience and optimization to access the width and height at the same time, but which is not required for anyone substituting one for the other.

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

The problem is that the square is a rectangle in the mathematical sense: a rectangle with ANY additional constraints while code which uses a rectangle expects a rectangle with NO further constraints.

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.

As niklasjansson points out, this solution breaks Liskov substitution. Squares programmed in such a way are no longer substitutable for rectangles. Breaking Liskov substitution is a great way to hide bugs and make your codebase extremely hard to reason about, due to the fact that every subtype can have drastically different behavior than what's defined by the parent type.

But then both are just a kind of polygon, with an arbitrary number of sides of arbitrary length.

At which point you really want a variable length list of Sides, each with a length property.

Or you want a series of points with relative coordinates, making the sides implicit.

Or or or...

What I take from it is that there is no one true object model, there is no universally "correct" way of solving the problem. An evolving understanding of the problem leads to an evolving solution that places different priorities on different attributes.

Is there any value provided to the system by making Square a specialisation of Rectangle? Is there value in being able to express a Square without a redundant attribute value? What is the tradeoff? And so on.

It's interesting because it highlights that if a thing has so many properties describing what it is, then at a certain point it's not a thing at all, but a collection of characteristics that could be tweaked to describe anything.

At that point, the idea of behaviors is rendered void, as the universe of possible behaviors is just too large.

So, I think that's the guiding principle in your suggestion to consider what value a given design provides to the system: that is, start by modelling the behaviors your system requires, then create an object hiearchy that reflects those behaviors most concisely.

This is probably our intent, but we may be derailed by too little respect for YAGNI.

This is a very insightful point. These models and concepts are all human created abstractions.

They contain elements of arbitrariness, describe different levels of detail, focus in on certain aspects or dynamic, leave out other information, and so on.

The skilled software developer must determine how useful and well-suited any particular abstraction is for the actual problem at hand, and judiciously move forward that.

As understanding of the problem domain grows, the abstractions should be updated and discarded to reflect this.

Pragmatism is key -- what does the system actually need to do? Supposed platonic ideals of some conceptual object are often a wild goose chase. Reality is complex. We must embrace it.

Yes! The thing that ends up breaking in the squares and rectangles examples is mutability. Remember that math things are immutable by default. This thing is a square, and by definition also a rectangle, and since its properties and identity are immutable, that will always be true.

However, programming takes those immutable concepts and tends to make them mutable. So now we have a rectangle, and we can change its identity by, say, scaling its width. And it's obvious that scaling just the width of a square will make it no longer a square. So now a square cannot support the same operations that a rectangle can. So now a square is no longer Liskov-substitutable for a rectangle.

Excellent point! I think it's fair to say that substitutability can only be satisfied (in general) for a fixed set of operations. This is why I believe Haskell's (and by extension Rust's) approach to bounded ad-hoc polymorphism is the best that I've seen in a production language. Going beyond Haskell, Rust also allows you to choose static dispatch, making bounded polymorphism zero cost. Dynamic dispatch is still available, when desired or needed (but it's almost never needed).

I'm a huge fan of the Rust and Haskell systems for exactly this reason. I sometimes play with the idea of a language that has that kind of type system, but with a more forgiving environment Rust or Haskell. Something like C#, but swap out the type system to feel more like Rust.

Perfect! This is the covariant/contravariant/invariant distinction, right?

"Read-only data types (sources) can be covariant; write-only data types (sinks) can be contravariant. Mutable data types which act as both sources and sinks should be invariant." from https://en.wikipedia.org/wiki/Covariance_and_contravariance_...

Absolutely, and that's another excellent way to explain the problem and come to the same conclusion. The mathematical relationship between rectangles and squares is covariant, because squares have more specific constraints than rectangles. But when you make rectangles mutable, those mutations are contravariant, because they only guarantee to preserve less specific constraints. So you can't make squares from mutable rectangles!

> 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 "if a specific implementation can mutate in ways that invalidate the laws expected of it, and you can't mutate the laws expected of it to match, your implementation might not match expectations". "Might not", because relaxed and pruned expectations may be locally sufficient.

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 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.

Sum types! I don't get to use that kind of stuff very much, so I tend not to think about them off the top of my head :)

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?

This is far from a silly example; it gets right to the core of the matter. As belorn mentioned, a square is a constrained rectangle, and inheritance by extension cannot represent this relationship.

Inheritance can represent this relationship, as long as all the defined operations in the rectangle are covariant. Because squares are covariant (more constrained) than rectangles. This generally means that the rectangle type must be immutable.

Indeed, but unfortunately these complications almost never comes up when programming in current mainstream object-oriented languages is taught. Usually, the take-home lesson is, "if you have a type hierarchy, use inheritance - it's simple."

You are absolutely right that there is an education problem. I got lucky by randomly deciding to take the OOP principles elective. It's still not a required course at my school, though I know from recruiting trips that other schools include it.

I think there's a place for a language that separates inheritance from subtyping. A lot of misuse of inheritance that I see comes from inheriting for functionality instead of subtyping.

> square is a constrained rectangle, and inheritance by extension cannot represent this relationship

A hypothetical nice type system, providing a push-out (path independent) lattice of theories/algebras (eg triples of types, operators, and laws) can represent this relationship by extension. It's just adding a law.

That we don't have such a type system available, is I suggest, perhaps the most crippling characteristic of our current tooling. But given the levels of type system research funding over the last decades, it's rather a self-inflicted injury. :/

Agreed, though I feel that phrasing it as 'adding a law' to include it under the umbrella of 'extension' tends to diminish, or distract from, the problem with inheritance as implemented in current mainstream languages. What you are describing seems to be a fundamentally different way of looking at the issue.

Fair. It seemed worth mentioning the larger context, and this seemed a plausible place.

Doing VR/AR, I've been struck by how not good the community is at attributing design constraints to cause. Constraints are simply echoed ("90 fps or sick!"), without attention to their context and scope of validity. Being unable to clearly see one's design space, impoverishes imagination, planning, and outcomes.

Many of the comments on this page reminded me of that. And parts of the OP. We can usefully discuss whether the apocryphal shoemaker had better today prohibit his oft-crippled children from dancing, or going outside, or walking, but it's worth bearing in mind that the root cause of the cripplings is the ongoing failure to provide shoes. And all the rusty bent nails we've left on the floor.

> but as models get more complex, it becomes harder to make them compatible

One thing that helps, is locally-scoped facades, like ruby's refinements.[1] You don't need complete model substitutability, only locally-sufficient substitutability.

[1] https://ruby-doc.org/core-2.5.0/doc/syntax/refinements_rdoc....

The thing is, rectangles are a kind of square, and squares are a kind of rectangle, from different perspectives.

From what perspective is a rectangle a kind of square?

From a write-only perspective. If you imagine mutating operations that square might have (for example setSideLength) rectangles can satisfy them perfectly well.