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

Inheritance was invented as a performance hack (2021)

catern.com

Post reply on HN
Print view View original

121–130 of 252 posts

Re: Inheritance was invented as a performance hack (2021)

#121

Post by ffsm8 »

yorwba wrote: post #104
ffsm8 wrote: post #85

Earlier quoted context omitted.

As a full stack developer who's current job is mostly Java on the backend - at least for the last 8 yrs: I'm not aware of anything you would lose by switching to interfaces with default implementations over inheritance... And that's the usual argument: use composition over inheritance.

But would switching to interfaces with default implementations fix any of the complaints that people have about inheritance? In my mind, they're pretty much equivalent, so it seems to me that anything you can do with inheritance that people complain about, you could also do with interfaces and complain about it in the same way.

The biggest difference are

1. A class can be composed out of multiple interfaces, making them more like mixins/traits etc vs inheritance, which is always a singular class

2. The implementation is flat and you do not have a tree of inheritance - which was what this discussion was about. This obviously comes with the caveat that you don't combine them, which would effectively make it inheritance again.

Re: Inheritance was invented as a performance hack (2021)

#122

Post by josephg »

Klonoar wrote: post #118
RHSeeger wrote: post #114

Earlier quoted context omitted.

> First, traits don't define any fields. How does one handle cases where fields are useful? For example, imagine you have a functionality to go fetch a value and then cache it so that future calls to get that functionality are not required (resource heavy, etc). // in Java because it's easier for me public interface hasMetadata { Metadata getMetadata() { // this doesn't work because interfaces don't have fields if (t…

Getters and setters that get specified by the implementing type.

Yep. Or ... don't put that in the interface at all. It looks like an implementation concern to me.

Re: Inheritance was invented as a performance hack (2021)

#123

Post by RHSeeger »

josephg wrote: post #122
Klonoar wrote: post #118

Earlier quoted context omitted.

Getters and setters that get specified by the implementing type.

Yep. Or ... don't put that in the interface at all. It looks like an implementation concern to me.

But if there's a lot of classes that implement the same thing, then not duplicating code makes sense. And saying "it's an implementation detail" leads to having the same code in a bunch of different classes. It feels very similar to the idea of default implementations to me; when the implementation will be the same everywhere, it makes sense to have it in one place.

Re: Inheritance was invented as a performance hack (2021)

#124

Post by RHSeeger »

Klonoar wrote: post #118
RHSeeger wrote: post #114

Earlier quoted context omitted.

> First, traits don't define any fields. How does one handle cases where fields are useful? For example, imagine you have a functionality to go fetch a value and then cache it so that future calls to get that functionality are not required (resource heavy, etc). // in Java because it's easier for me public interface hasMetadata { Metadata getMetadata() { // this doesn't work because interfaces don't have fields if (t…

Getters and setters that get specified by the implementing type.

But then you have the getters, setters, and field on every class that implements the functionality. It works, sure, it just feels off to me. This is code that will be the same everywhere, and you're pulling it out of the common class and implementing it everywhere.

Re: Inheritance was invented as a performance hack (2021)

#125

Post by [deleted] »

osigurdson wrote: post #28
roenxi wrote: post #10

I'm not sold the evidence is there to show inheritance is a good idea - it basically says that constructors, data storage and interfaces need to be intertwined. That isn't a very powerful abstraction, because they don't need to be and there isn't an obvious advantage from doing so over picking up the concepts separately as required. And inheritance naturally suggests grouping interfaces into a tree in the way that se…

Yeah ya... everyone likes to go on and on about how inheritance is the root of all evil and if you just don't use it, everything will be fine. Sorry, it won't be fine. Your software will still be a mess unless it is small and written three times by the same person who knows what they are doing. The bottom line is, no one ever really used inheritance that much anyway (other than smart people trying to outsmart themsel…

[deleted]

Re: Inheritance was invented as a performance hack (2021)

#127

Post by josephg »

inglor_cz wrote: post #112
josephg wrote: post #90

Earlier quoted context omitted.

Botanical trees appearing in nature don't make them "the fundamental truth of things". And in what way are trees the basis of human society? Thats such a strange claim. Are you talking about family trees? Because they're actually directed acyclic graphs. Even if you want to claim that trees are a common data structure, that doesn't mean they're appropriate in any specific case. Should we therefore arrange all website…

"Taxonomies are entirely and completely worthless." Hard disagree. Knowing that AES and Twofish are block ciphers is useful when dealing with cryptography. Many categories of algorithms and objects are naturally taxonomic. Even HTML+CSS has (messy) inheritance.

I may have overstated the claim in that sentence. More accurately, I think taxonomies aren't, themselves, useful. If they don't help you solve problems, you're just stamp collecting. I've seen that happen way too many times - otherwise smart people thinking they're being productive by writing a whooole lot of useless classes, where a few functions and some if statements would do it.

But don't get me wrong - I'm totally in favour of having common interfaces. They aren't great because they form a taxonomy. They're great because it helps us abstract. Whether its Iterator or different software implementing HTTP, interfaces actually help us solve actual problems.

> Knowing that AES and Twofish are block ciphers is useful when dealing with cryptography.

The useful fact in this example is that they both do a similar thing. They form a type class from their common behaviour. Behaviour they may share with - for example - a compression algorithm. Thats what actually matters here.

Re: Inheritance was invented as a performance hack (2021)

#128

Post by josephg »

RHSeeger wrote: post #123
josephg wrote: post #122

Earlier quoted context omitted.

Yep. Or ... don't put that in the interface at all. It looks like an implementation concern to me.

But if there's a lot of classes that implement the same thing, then not duplicating code makes sense. And saying "it's an implementation detail" leads to having the same code in a bunch of different classes. It feels very similar to the idea of default implementations to me; when the implementation will be the same everywhere, it makes sense to have it in one place.

So to be clear about your example: You have a whole lot of different - totally distinct - types of things, which all need to have the same logic to cache HTTP requests? Can you give some examples of these different types you're creating? Why do you have lots of distinct types that need exactly the same caching logic?

It sounds like you could solve that problem in a lot of different ways. For example, you could make an HTTP client wrapper which internally cached responses. Or make a LazyResource struct which does the caching - and use that in all those different types you're making. Or make a generic struct which has the caching logic. The type parameter names the special individual behaviour. Or something else - I don't have enough information to know how I'd approach your problem.

Can you describe a more detailed example of the problem you're imagining? As it is, your requirements sound random and kind of arbitrary.

Re: Inheritance was invented as a performance hack (2021)

#129

Post by RHSeeger »

int_19h wrote: post #98
DaiPlusPlus wrote: post #52

Earlier quoted context omitted.

> How are interfaces with ability to provide default implementations for members (which both C# and Java allow today) not a substitute for mixins? Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself. Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties…

> Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself. That's true in C# but not in Java, so it's not something intrinsic to the notion of an interface. > Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties, and events - which are all fundamentally ju…

Making the class add 2 methods and a field for every place the interface would define a field adds noise. And if you have a class with 20 interfaces, that can be a lot of noise. When you consider that the class itself doesn't actually need to know anything about the field because only the interface uses them, it's just... ugly.

Re: Inheritance was invented as a performance hack (2021)

#130

Post by codr7 »

josephg wrote: post #58
codr7 wrote: post #38

Earlier quoted context omitted.

But they're not building trees, that's how inheritance is mostly used today. After reading this, I'm thinking that intrusive lists is the one use of inheritance in C++ that makes any sense.

I'd still generally prefer intrusive lists to be done via composition. I've seen plenty of intrusive lists where each item was a member of multiple lists at the same time - which is quite hard to do if you need to inherit from an intrusive list element superclass.

metoo, but how do you pull that off in C++? How do you get back from node to containing value?

Multiple inheritance, possible but you'd have to jump some hoops to disambiguate since you're dealing with multiple copies of the same base class.

Post reply on HN