Inheritance Often Doesn't Make Sense • Hacker News Board

Re: Inheritance Often Doesn't Make Sense

#91

Post by seanmcdirmid » Sat, Mar 17, 2018, 2:05 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…

Values should be immutable even in OO languages. A point’s x and y coordinates can’t be mutated because then it would be a different, just like a number’s value can’t be mutated. The question is then is a rectangle a value or an object? I would say no and then stack allocate it like any other value, recomputing it if a rect property ever changed.

The real world has both values and objects, any ideology that doesn’t acknowledge both is just fooling itself.

Re: Inheritance Often Doesn't Make Sense

#92

Post by seanmcdirmid » Sat, Mar 17, 2018, 2:07 PM UTC

greydius wrote: post #74

duncanawoods wrote: post #30

Earlier quoted context omitted.

> 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 Only if you ignore time. It's not possible to change the state of the world at some previous instant (as far as our understanding of physics is concerned). The mutable world model is an artificial construction that aligns with our human perception.

Something that changes over time is mutable. Time exists and we can’t escape it, even with time-indexed immutable data structures that implement explicit mutability. The only question is does the thing change internally (an object) or is it replaced with a new one (a value).

Re: Inheritance Often Doesn't Make Sense

#93

Post by m3kw9 » Sat, Mar 17, 2018, 2:08 PM UTC

scarygliders wrote: post #73

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much m…

And you are probably in the same situation when he was in when he realized it’s too much to re write and so he continued down the path. The next person will have the same issues as you until one of you can get Managment to let you rewrite it.

Re: Inheritance Often Doesn't Make Sense

#94

Post by m3kw9 » Sat, Mar 17, 2018, 2:10 PM UTC

scarygliders wrote: post #73

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much m…

Inheritance was probably was a good idea for a small thing and quickly achieve certain goals until features ballooned and he keep promising to deliver more features on top promptly

Re: Inheritance Often Doesn't Make Sense

#95

Post by seanmcdirmid » Sat, Mar 17, 2018, 2:12 PM UTC

weberc2 wrote: post #90

sbov wrote: post #38

Unless your program's goal is to ontologically categorize objects, #1 is a trap that will just bite you in the ass. In the physical world, if I have a rectangle shaped box I want to cover, I don't want a square, no matter how much "squares are rectangles". It's no different in a program. What really matters is the behavior and goals of your program. It's cute to say squares are rectangles but if your program needs to…

> Unless your program's goal is to ontologically categorize objects, #1 is a trap that will just bite you in the ass. Strangely, ontological inheritance isn't even useful for that purpose. If you're organizing things ontologically, you certainly want to have runtime access to the relationships in your ontology, which means you should model things as data, not static class relationships (although reflection can turn s…

Most languages that have classes expose inheritance relationships in someway without reflection. Even JavaScript provides a non-reflective instanceof now. You can also reify inheritance relationships more directly by hand of needed.

Re: Inheritance Often Doesn't Make Sense

#96

Post by Ace17 » Sat, Mar 17, 2018, 2:13 PM UTC

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…

> The conceptual purist perspective: > > The notion of object oriented programming is completely misunderstood. It's not about objects and classes, it's all about messages. - Alan Kay >

Given that Alan Kay is the one who came up with the term "object oriented", it might be wise to give him authority about the definition.

Re: Inheritance Often Doesn't Make Sense

#97

Post by lostcolony » Sat, Mar 17, 2018, 2:22 PM UTC

weberc2 wrote: post #84

scarygliders wrote: post #73

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much m…

I agree. I never find myself with a scenario in which inheritance is useful. I actually started writing a lot of Go (which has no inheritance support) and haven't missed inheritance at all. It really seems like useless complexity.

I've found one or two cases where "inheritance would be nice". It wasn't necessary.

I've found so many cases like the OPs where it made things harder, and the fix was basically pulling apart all shared functionality, where the only thing inherited were interfaces (if even that).

Re: Inheritance Often Doesn't Make Sense

#98

Post by mannykannot » Sat, Mar 17, 2018, 2:27 PM UTC

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…

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.

Re: Inheritance Often Doesn't Make Sense

#99

Post by FLUX-YOU » Sat, Mar 17, 2018, 2:28 PM UTC

m3kw9 wrote: post #94

scarygliders wrote: post #73

I took over the maintenance and enhancement of a customer's eCommerce site. It's written in Python, using an ancient framework - Pylons. The person who originally designed and wrote it, coded large super classes and then subclassed off those. And then somtimes subclassed off those subclasses. So now I'm lost in a maze of twisty classes/subclasses, which makes maintaining and enhancing this eCommerce site much, much m…

Inheritance was probably was a good idea for a small thing and quickly achieve certain goals until features ballooned and he keep promising to deliver more features on top promptly

OO and inheritance can be brittle when you get new features that affect a wider amount of existing code. If you're only adding stuff on incrementally, you can conceivably add new classes for all of it and not worry about working with the existing code (usually you likely have some business classes that are basically starting primitives for new features, e.g. Customer).

As it gets more brittle, it gets harder to add those spanning features, especially if it's not clear what features will be asked for.

Re: Inheritance Often Doesn't Make Sense

#100

Post by Ace17 » Sat, Mar 17, 2018, 2:29 PM UTC

kccqzy wrote: post #15

> A common counterexample to OO inheritance is the relationship between a square and a rectangle. Geometrically, a square is a specialisation of a rectangle: every square is a rectangle, not every rectangle is a square. Alternatively, you can argue that a rectangle is just a square with the additional freedom to vary the width and height independently. So in C++ syntax you would have: class Square { protected: size_t…

You reduced the "Square" class to a convenient implementation helper.

Whatever type they choose to use, clients of your class hierarchy now only see one interface: getWidth/getHeight. And they can't make assumptions based on the type they see, as both "Square" and "Rectangle" might have "getWidth()!=getHeight()". So they must handle the generic "rectangular" case.

So, for the client, there's absolutely no visible difference between a "Square" or a "Rectangle". Which means there's no point in dealing with two classes anymore : all client code will then take "Square" objects, and deal with them as geometrical rectangles.