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

141–150 of 255 posts

Re: Inheritance Often Doesn't Make Sense

#141

Post by gugagore »

jdmichal wrote: post #88
panic wrote: post #9

A couple of other comments have argued that "ontological inheritance" and "abstract data type inheritance" are actually the same thing: > This is because Squares are Liskov substitutable for Rectangles... which is because Squares are, platonically, a kind of Rectangle. > If the type system is sound and expressive enough, ontological inheritance ( this thing is a specific variety of that thing) and abstract data type…

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…

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

Re: Inheritance Often Doesn't Make Sense

#142

Post by neokantian »

In practical terms, away from the nebulous confusion, object orientation means that the actual function to call must first be looked up in the first argument of the function to execute:

x.f(y,z);

F=ooLookup(x,f); F(x,y,z);

This scheme does indeed allow for polymorphism, but I wonder why we would shoehorn polymorphism into a situation, unless it naturally emerges throughout the programming effort as really needed?

In my opinion, functions should not be polymorphic by default, simply, because there is no reason to complicate things unless these complications truly solve a problem.

Inheritance is then a next complication in which F=ooLookup(x,f) recursively tries to resolve the function from a hierarchical class data structure:

x->class->functions

x->class->class->functions

...

This is even a worse complication, which is even more unlikely to be useful.

Re: Inheritance Often Doesn't Make Sense

#143

Post by coldtea »

c22 wrote: post #135
coldtea wrote: post #108

Earlier quoted context omitted.

> Why am I not convinced with the given example? Because fundamentally, I don't think "set the width and height" counts as something you can do with a rectangle. A rectangle has a width and height, 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. Sure you can. You can both dictate it its width and height at construction time (e.g. the table maker…

The carpenter has certainly altered the dimensions of the board , but in so doing has he not destroyed the old rectangle and created a new one?

No. Even less so with the pastry dough squashed into new dimensions.

Or when a citizen turns into a soldier -- an army camp is like a soldier factory/constructor. Hmm, how's that for a mixed metaphor?

Re: Inheritance Often Doesn't Make Sense

#144

Post by platinumrad »

contingencies wrote: post #7

The programmer's perspective: The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham. Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998. The problem w…

How does dropping a bunch of out of context quotes contribite to a discussion? Why was this voted to the top? Clearly I should just skip the first comment tree entirely when reading comments on pieces about "programming paradigms."

Re: Inheritance Often Doesn't Make Sense

#145

Post by greydius »

seanmcdirmid wrote: post #138
greydius wrote: post #134

Earlier quoted context omitted.

> Bob at time t is still Bob at t+1 I guess we're getting more into philosophical issues now. If I leave an ice cube on my counter, at exactly what time is it no longer an ice cube.

Mutability is mutability, it also applies to ontology even if most OO languages don’t model dynamic ontology with inheritance (unlike say Self or Cecil). Your ice cube was never just an ice cube in the first place, it was just some water that happened to be frozen as a cube...once heat was applied to the water, it’s state changed so that it eventually could no longer be classified as an ice cube.

> Your ice cube was never just an ice cube in the first place

That's my point. This idea that there are objects with mutable state is a myth. Even at the smallest scale, what we call elementary particles, are abstractions. There is nothing except the state of the universe at a given instant in time.

Re: Inheritance Often Doesn't Make Sense

#146

Post by always_good »

TheOtherHobbes wrote: post #116
contingencies wrote: post #7

The programmer's perspective: The phrase 'object-oriented' means a lot of things. Half are obvious, and the other half are mistakes. - Paul Graham. Implementation inheritance causes the same intertwining and brittleness that have been observed when goto statements are overused. As a result, OO systems often suffer from complexity and lack of reuse. - John Ousterhout Scripting, IEEE Computer, March 1998. The problem w…

I think the problem is more that OOP and FP teach that the solution is in the language constructs, when in fact the solution is in the developer. OOP and FP are typically taught as outputs. You take a problem, you apply FP or OOP magic, and you get a solution squeezed into an FP or OOP shape. The implication is that the language somehow half-solves your problem just by being how it is, and all you have to do is apply…

The solution is in the ecosystem.

Having discipline doesn't do much good when everything else you interact with lacks it.

Re: Inheritance Often Doesn't Make Sense

#147

Post by seanmcdirmid »

greydius wrote: post #145
seanmcdirmid wrote: post #138

Earlier quoted context omitted.

Mutability is mutability, it also applies to ontology even if most OO languages don’t model dynamic ontology with inheritance (unlike say Self or Cecil). Your ice cube was never just an ice cube in the first place, it was just some water that happened to be frozen as a cube...once heat was applied to the water, it’s state changed so that it eventually could no longer be classified as an ice cube.

> Your ice cube was never just an ice cube in the first place That's my point. This idea that there are objects with mutable state is a myth. Even at the smallest scale, what we call elementary particles, are abstractions. There is nothing except the state of the universe at a given instant in time.

Again, we are unable to work or perceive at that level. So the abstraction of state is incredibly useful to us non-sub-atomic beings.

Re: Inheritance Often Doesn't Make Sense

#148

Post by PKop »

kqr wrote: post #140
Jare wrote: post #72

Earlier quoted context omitted.

> if you ask me for any rectangle, and you reject a square, you are wrong No, no: "If you ask me for any object that can have independent width and height, and you reject a Square, you are..." right, of course. It depends on the properties that define what a Rectangle and a Square are in your code.

> No, no: "If you ask me for any object that can have independent width and height, and you reject a Square, you are..." right, of course. It depends on the properties that define what a Rectangle and a Square are in your code. I think you nailed an important distinction here, but maybe used the wrong words in doing so. The correct definition of a rectangle, with this interpretation, is any object that can change its…

I don't think the "that can change" characteristic is important here.

You can declare that "for all values of width and height, w does not have to equal h" to be valid. Mutability is irrelevant.

Re: Inheritance Often Doesn't Make Sense

#149

Post by kqr »

PKop wrote: post #148
kqr wrote: post #140

Earlier quoted context omitted.

> No, no: "If you ask me for any object that can have independent width and height, and you reject a Square, you are..." right, of course. It depends on the properties that define what a Rectangle and a Square are in your code. I think you nailed an important distinction here, but maybe used the wrong words in doing so. The correct definition of a rectangle, with this interpretation, is any object that can change its…

I don't think the "that can change" characteristic is important here. You can declare that "for all values of width and height, w does not have to equal h" to be valid. Mutability is irrelevant.

But a rectangle as traditionally defined can have equal dimensions. Consider the rectangle whose width slowly grows to be longer than the height. Surely it does not skip a value because it happens to equal the height?

Re: Inheritance Often Doesn't Make Sense

#150

Post by PKop »

kqr wrote: post #149
PKop wrote: post #148

Earlier quoted context omitted.

I don't think the "that can change" characteristic is important here. You can declare that "for all values of width and height, w does not have to equal h" to be valid. Mutability is irrelevant.

But a rectangle as traditionally defined can have equal dimensions. Consider the rectangle whose width slowly grows to be longer than the height. Surely it does not skip a value because it happens to equal the height?

"does not have to be equal" != "can't be equal".

The set of all possible rectangles have w and h that can be different (or the same) values.

Post reply on HN