Inheritance Often Doesn't Make Sense • Hacker News Board

Re: Inheritance Often Doesn't Make Sense

#151

Post by skybrian » Sat, Mar 17, 2018, 5:36 PM UTC

kqr wrote: post #136

skybrian wrote: post #118

Earlier quoted context omitted.

Yes, the problem is that mutable and immutable objects have different methods and therefore fit into different inheritance trees. If you construct an immutable rectangle and pass in the same width and height, you have a square. (An object implementing the same API could be implemented by a subclass whose constructor just takes a width.) If you construct a mutable rectangle with the same width and height, you have a r…

I actually don't think the problem is one of mutability/immutability – it's just that a mutable setting very clearly exposes the problem. I think the core of the problem is that the object model has permanently and irreversibly associated an identity to an object based on attributes that are actually malleable. Someone else made a good connection to pastry dough, which can be shaped even more freely. We would never h…

Yes, and that's directly related to immutability. Immutable objects are timeless; their initial state is their final state. Any property that holds for their initial state can be encoded in the type and placed somewhere above it in the inheritance hierarchy.

You can think of a mutable object as a collection of immutable and mutable properties, where only the former can be moved into the type and become part of the type hierarchy.

This distinction isn't really about inheritance; it's more about what a type is in the presence of mutability. The type represents the invariants.

Re: Inheritance Often Doesn't Make Sense

#152

Post by pulverizer » Sat, Mar 17, 2018, 6:10 PM UTC

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…

In real world you stretch a square and it may become a rectangle. So in OO even type of an object should be mutable if you want to model real world closely.

Re: Inheritance Often Doesn't Make Sense

#153

Post by GuiA » Sat, Mar 17, 2018, 6:15 PM UTC

divs1210 wrote: post #125

TheOtherHobbes wrote: post #116

Earlier quoted context omitted.

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…

I think the problem is more that Roman and Indo-Arabic numerals teach that the solution is in the notation, when in fact the solution is in the mathematician. . .

I’m confused about your analogy. Indo-Arabic number representation enables one to mentally carry out computations that would be much more complex in Roman notation. The notation might not be the solution, but the notation certainly enables solutions not really conceivable in other notations.

Re: Inheritance Often Doesn't Make Sense

#154

Post by geezerjay » Sat, Mar 17, 2018, 6:17 PM UTC

PaulStatezny wrote: post #114

psyc wrote: post #112

Earlier quoted context omitted.

That would be next to impossible, since the term is overwhelmingly used by working programmers in the context of C++/Java/C#/etc. Also, I suspect that the only reason Kay's version is even brought up in every discussion of the term is some sort of programmer-hipster signaling thing. Not that Kay's OO isn't important - it is. It's just hardly ever relevant to the actual discussion.

I really dislike this kind of hand-wavy dismissal of ideas/opinions as “programmer-hipster”. It seems to assume the person in question has no intelligent reason behind their thoughts/opinions. And it dismisses the opinion instead of engaging with it intellectually. And having been on the receiving end, it’s insulting. It feels like being called stupid. It’s fine to disagree with opinions, but when you assume people a…

> It seems to assume the person in question has no intelligent reason behind their thoughts/opinions.

If they had, they wouldn't systematically resort to baseless appeals to authority, whose only purpose is to intentionally avoid having to present any semblant of an intelligent reason.

Re: Inheritance Often Doesn't Make Sense

#155

Post by kerkeslager » Sat, Mar 17, 2018, 6:19 PM UTC

seanmcdirmid wrote: post #120

kerkeslager wrote: post #111

Earlier quoted context omitted.

I think it's not at all evident that reality is not a value replaced with a new one all the time.

Even if that were the case, it wouldn’t be useful since we experience time with continuity anyways. Bob at time t is still Bob at t+1 even if his state (like position) has changed. If Bob were a value, then he would be another person, we would have to add a persistent ID to the bob values so we could see them as the same object.

> Bob at time t is still Bob at t+1 even if his state (like position) has changed.

Again, I don't think this is at all evident.

What if we remove a limb? Give him a dose of LSD? Give him a brain tumor? Replace most of his cells as happens to each of us every few years? What change is large enough that it's easier to represent with:

   bob = getNext(bob);

...rather than:

   bob.foo = bar;

? Is it even harder to represent change one way rather than the other?

Indeed, socially, the concept of identity is a leaky enough abstraction to cause problems; for example if we are criticized for actions that we took years ago, it's easy to get defensive even if we are a different enough person now that we would never take that action now.

Bringing this back to inheritance: if it would make sense to model Bob as an instance of Child one day and as an instance of Octogenarian another day, why not create a new instance of Bob?

You want to argue this from the standpoint of "this is how things are" but I think that there are multiple ways to model Bob and which is appropriate actually depends more on the needs of the system than the true nature of Bob.

Re: Inheritance Often Doesn't Make Sense

#156

Post by seanmcdirmid » Sat, Mar 17, 2018, 6:27 PM UTC

kerkeslager wrote: post #155

seanmcdirmid wrote: post #120

Earlier quoted context omitted.

Even if that were the case, it wouldn’t be useful since we experience time with continuity anyways. Bob at time t is still Bob at t+1 even if his state (like position) has changed. If Bob were a value, then he would be another person, we would have to add a persistent ID to the bob values so we could see them as the same object.

> Bob at time t is still Bob at t+1 even if his state (like position) has changed. Again, I don't think this is at all evident. What if we remove a limb? Give him a dose of LSD? Give him a brain tumor? Replace most of his cells as happens to each of us every few years? What change is large enough that it's easier to represent with: bob = getNext(bob); ...rather than: bob.foo = bar; ? Is it even harder to represent ch…

Bob’s state might change, but he is still Bob. That would also go for the Ship of Theseus. However you represent it, change is still change, it is still mutability.

We can argue if identity is useful in real life, but most people cling to names and identity, it isn't a controversial subject.

Dynamic inheritance is extremely useful in a programming language, though only a few have it. It is a very OO concept, as are the languages that have explored the concept (e.g. Self, Cecil, among others, even Javascript has this aspect, though not focused enough to use very well).

Re: Inheritance Often Doesn't Make Sense

#157

Post by kerkeslager » Sat, Mar 17, 2018, 6:31 PM UTC

seanmcdirmid wrote: post #147

greydius wrote: post #145

Earlier quoted context omitted.

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

Agreed, but if we're accepting an abstraction instead of reality, than arguing for mutability because you think it's reality doesn't make much sense now does it? You're saying it's okay to abstract things away from molecules, but it's not okay to abstract things away from mutation. Why?

(Note that I'm not even persuaded yet that mutation is reality. I'm just saying that even if mutation were reality, it doesn't follow that mutation is the best abstraction with which to model reality.)

Re: Inheritance Often Doesn't Make Sense

#158

Post by ken » Sat, Mar 17, 2018, 6:42 PM UTC

I feel as though the rectangle/square example falls down mostly because of a linguistic trick.

Rect->Square could be a perfectly reasonable type hierarchy, as long as you don't allow self-mutation of the very attribute that defines this specialization. But then, mutation tends to wreak havoc on inheritance anyway (e.g., covariance/contravariance) -- and almost everything else. When I take the needle out of my record player, it can't play records any more, so is it really still a "record player"?

This isn't special to any particular type of inheritance, either. If you let all the air out of your ball, it's no longer a sphere, so even with purely ontological types, you're already in trouble. Inheritance isn't the problem. Mutation is.

Re: Inheritance Often Doesn't Make Sense

#159

Post by BeeOnRope » Sat, Mar 17, 2018, 6:51 PM UTC

bitwize wrote: post #137

psyc wrote: post #119

Earlier quoted context omitted.

I get what you're saying, but I'm still persuaded this is what happens with Kay and/or smalltalk. 100 times I've seen threads about OO. 99 times someone brought up Kay/smalltalk. Zero times did they specify why the messaging model was relevant to the present discussion. That's important to do, because more OO programmers use C++/C#/Java, and are not smalltalk experts. So, it seemed to me that they were namedropping.…

Duck typing is central to the Smalltalk "vision thing". That and the idea that a message is a symbolic representation of a method, which an object may or may not support. It is not, in fact, the method, nor does it stand for a direct call to the method. In C++ and Java, for a call to a.foo(12) the compiler can look up the class of a, determine whether it has a foo implementation, and if so compile a call directly wit…

> This is NOT true with C++, absent template metaprogramming...

So it is true in C++ then, right? It's only not true in "C++ minus templates" which is a language no one uses.

Re: Inheritance Often Doesn't Make Sense

#160

Post by DubiousPusher » Sat, Mar 17, 2018, 6:53 PM UTC

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 use it to circulate fluid. In the past, these parts were sometimes driven by another system or integrated directly into another part. But over time, as a convenience to many different parties it was decided they should all implement a pully and connect dirctly to one of the main belts that connect directly to the motor. Not a single one of these parts has anything you'd call a taxonomical relationship. They do have an invented one. And it is as much about conveniencing the overall system design as much as conveniencing the individual part design. They are all "pully implementers" subscribed to the "belt druve" system.

This is the inheritence I find most powerful in software. These things aren't the same but if we treat them the same, the downstream and upstream code are simpler, easier to replace and consistent. I don't worry too much about the philisophical relationship between the objects.