Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Inheritance Often Doesn't Make Sense

sicpers.info

Post reply on HN
Print view View original

231–240 of 255 posts

Re: Inheritance Often Doesn't Make Sense

#231

Post by jwdunne »

baddox wrote: post #229
dllthomas wrote: post #228

Earlier quoted context omitted.

It may have been edited, but at least presently the comment you replied to asks for an example of inheritance.

Oh rats, my mistake. It is harder to come up with s good example of mechanical inheritance. Something like the cassette tape adapter kinda feels like inheritance, in the sense that it can be substituted in for a normal cassette tape but provides its own unique functionality.

Yes, I'm struggling to think of a good mechanical example of inheritance as code reuse.

But I don't agree with the "that's an interface, not inheritance" argument. Well designed super classes tend to provide an interface - they just don't use the "interface" keyword.

If you declare a method as abstract, you're defining an interface that subclasses use to define new behaviour. You see this all the time. If a method is defined as protected, you're saying "I'm allowing subclasses to use this interface to change behaviour".

For example, test frameworks usually provide an overridable method that's run before each test - setUp. That's interface - "I will call setUp before every test - feel free to override it".

To me, that's where shit gets hard. It has to have a well defined interface, it has to be an is-a relationship and it has to be a subtype (Liskov). That's why we see composition over inheritance because it's far simpler to just drop one of the constraints and get decent work done.

Re: Inheritance Often Doesn't Make Sense

#232

Post by your-nanny »

kerkeslager wrote: post #106
kaoD wrote: post #78

Earlier quoted context omitted.

"Everything changes and nothing remains still; you cannot step twice into the same stream"

Ironically, the latter part of what you quoted shows the solution to representing change in an immutable system: create a different stream object instead of mutating the same stream object. (Streams in this case not being streams in an I/O sense, just an example of a class).

Meh. Once you mutate an object it is not the same object it once was either; you've only maintained a stable memory reference and alias, without the overhead of making a new one.

Re: Inheritance Often Doesn't Make Sense

#234

Post by mannykannot »

mncharity wrote: post #222
mannykannot wrote: post #98

Earlier quoted context omitted.

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.

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

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.

Re: Inheritance Often Doesn't Make Sense

#235

Post by mannykannot »

jdmichal wrote: post #176
mannykannot wrote: post #98

Earlier quoted context omitted.

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

Re: Inheritance Often Doesn't Make Sense

#236

Post by chiefalchemist »

I'm not convinced the sqr rect example is the best one, at least to say inheritance is wrong. I think this is an example of how not to use inheritance. In my mind the base class should be shape (not rect) or four-sided shape, or whatever the name is for shapes with non-curved sides.

Just me?

Re: Inheritance Often Doesn't Make Sense

#237

Post by mncharity »

mannykannot wrote: post #234
mncharity wrote: post #222

Earlier quoted context omitted.

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

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.

Re: Inheritance Often Doesn't Make Sense

#238

Post by arximboldi »

duncanawoods wrote: post #30
kqr wrote: post #20

> you cannot use a square everywhere you can use a rectangle (for example, you can’t give it a different width and height) Can someone come up with a better example here? Intuitively, I would say, "Yes, if you ask me for any rectangle, and you reject a square, you are wrong." If you say you can use any rectangle to do your thing, you should absolutely be able to also use a square. Why am I not convinced with the give…

> and you can't just will it to have a different width and height and expect it to obey you through some force of nature I think you have let functional programming and immutable data-structures bias your world view. The real world is mutable and the wonder of the digital mutable world is that it is pretty much just will-alone that can set attributes as you describe. It is immutability that is a trendy but artificial…

The real world is mutable in some sense, but our thinking, even in the most trivial exercises, works by detaching _objects_ them from their physical nature and building immutable _ideas_. Thinking is a struggle trying to find what is necessary in a contingent world, trying to find essence in a world of form. That is why values and immutability are so useful for modeling, architecture, and building resilient software.

I talked more about this in this MeetingC++'17 talk: https://www.youtube.com/watch?v=NMol_5-2owo

Re: Inheritance Often Doesn't Make Sense

#239

Post by jdmichal »

mannykannot wrote: post #235
jdmichal wrote: post #176

Earlier quoted context omitted.

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.

Re: Inheritance Often Doesn't Make Sense

#240

Post by jdmichal »

mncharity wrote: post #221
jdmichal wrote: post #88

Earlier quoted context omitted.

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 iden…

> 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.
Post reply on HN