3 ms·

Inheritance is great, just depends how you use it. I've never once reached for it for building servers. For games? All the time.

echelon 9mo ago
The only two domains where I've felt inheritance is useful are video games and windowing systems. Inheritance is actually useful for Widget > Input > TextBox since methods and behaviors do follow parent-child and even sibling relationships. But there aren't many domains like this. Rust and other languages choosing traits and type classes instead of strict species-oriented class inheritance seems like the much more modern and more widely applicable approach. Classes feel clinical and dated.
- llmslave2 9mo ago
  Anything where you have literal "instances" of something with common state/behaviour is prime for inheritance, but that's different from trying to model a domain as a set of hierarchal objects. But I do like classes - you can use them without inheritance, and the other stuff that comes with them (encapsulation, polymorphism, etc) fits my mental model. [0] Classes are just syntactic sugar over closures at the end of the day. But inheritance is best when it's limited and shallow. 0: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
  - ahartmetz 9mo ago
    I guess closures in languages like Scheme can have multiple "methods"? In C++ and Rust, closures (lambdas) are one function with attached state variables. I guess there are ways to attach more callables to a bag of state, but they would involve one lambda for each callable and shared state captured by reference (and good luck dealing with lifecycle issues).
    - llmslave2 9mo ago
      You can do it multiple ways. Like in go: cloj := func() { val := 1 return func(m string) { switch m { case "inc": val = val + 1 case "dec": val = val - 1 } } } () cloj("inc") In JS you can close upon state and return an object, which is essentially how classes work in the language. let cloj = (() => { let x = 0; return { inc: () => x++, dec: () => x-- } })() cloj.inc()
    - gpderetta 9mo ago
      a tuple of closures closing over the same object ('let over lambda') is equivalent to an interface.
    - antonvs 9mo ago
      > I guess closures in languages like Scheme can have multiple "methods"? At the language implementation level, Scheme-like closures only have one operation, which is the ability to apply them to arguments and thus evaluate them. But as a couple of the other replies show, a closure's code can be implemented as a dispatcher which handles multiple methods. That's not a language feature, just user code. I wrote the koan quoted above in 2003, a few years before Graydon Hoare started working on Rust. At the time, there weren't any "static" languages with built-in support for closures. Even Python had only had read-only closure support for a couple of years at that point - so those closures couldn't be used to implement mutation of closed-over variables. (Python didn't get mutable closures until around 2008.) Java only got closure support in version 8 around 2014. C++ 11 got closures in 2011. Of course you can implement dynamic-dispatching objects using closures in Rust or C++, but that's not going to be the equivalent of a statically-defined structure.
- bonesss 9mo ago
  In addition to the underlying domain (and I agree, it’s no coincidence that windowed GUI widgets are common in in OOP textbooks), there’s also overlapping spectrums of language expressiveness and object-orientedness to consider. The principle of least surprise, bad evil and scary techniques in general might be the orthodox, efficient and intuitive for maintainers in context. Templates in GUI frameworks versus business apps, for example.
flohofwoe 9mo ago
> For games? All the time. Hmm, but game objects is exactly the popular use case where traditional inheritance breaks down first and composition makes much more sense? That's why the whole Entity-Component idea came up decades ago (like in Unity, long before the more modern column-database-like ECS designs).
- llmslave2 9mo ago
  Entity systems still rely on inheritance as you typically have an Entity baseclass that all entities derive from. That's just a single level of inheritance. Unity does this through MonoBehavior. Unreal is more inheritance-heavy but developers typically subclass something like `Actor` to one level of additional inheritance beyond the Engine's subclasses. A lot of engines will have multiple superclasses behind a Entity class, but that's an implementation detail of the engine itself and to the game developer, it's treated as a single base class that is typically subclassed a single time for the entity itself. Even in ECS's you will often find inheritance. Some implementations have you inherit a Component struct, others will have the systems inherit a System class. I'm sure it's still used today in some engines and by some developers but the overwhelming opinion is that doing something like Entity -> Actor -> Monster -> Orc -> IceOrc is a bad idea. Instead it would be like class IceOrc : Entity { components {Health, Enemy, PlayerSeek, Position, etc} } Where each component is like class Health : Component { value = 100 } And yeah, they favour composition re. Components, it's just that the components tend to inherit from a Component class. But I would still call it composition!
  - flohofwoe 9mo ago
    Yes there is some inheritance left in those composition-systems, but a single inheritance level is really more like implementing an interface.
    - llmslave2 9mo ago
      It is, but you get the benefit of shared behaviour and state. Like an Entity might have a Position, a reference to the World, the Screen, methods for interacting with other entities, etc. You don't get that from simply implementing an interface, although it's not difficult to pass those into the object. A common example I've seen is having every class extend an EventEmitter superclass. You could implement that as part of the interface but that becomes a ton of duplication. I think of it like this: If you model your domain as something like `A : B : C : D {}` you get all the problems of inheritance, when simply doing D { A; B; C; } gives you the same benefits without the problems. Doing `A : X {}, B : X {}, C : X {}` sidesteps most of the problems with inheritance but gives you some of the benefits as well.

echelon 9mo ago

The only two domains where I've felt inheritance is useful are video games and windowing systems. Inheritance is actually useful for Widget > Input > TextBox since methods and behaviors do follow parent-child and even sibling relationships. But there aren't many domains like this. Rust and other languages choosing traits and type classes instead of strict species-oriented class inheritance seems like the much more modern and more widely applicable approach. Classes feel clinical and dated.

llmslave2 9mo ago
Anything where you have literal "instances" of something with common state/behaviour is prime for inheritance, but that's different from trying to model a domain as a set of hierarchal objects. But I do like classes - you can use them without inheritance, and the other stuff that comes with them (encapsulation, polymorphism, etc) fits my mental model. [0] Classes are just syntactic sugar over closures at the end of the day. But inheritance is best when it's limited and shallow. 0: The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
- ahartmetz 9mo ago
  I guess closures in languages like Scheme can have multiple "methods"? In C++ and Rust, closures (lambdas) are one function with attached state variables. I guess there are ways to attach more callables to a bag of state, but they would involve one lambda for each callable and shared state captured by reference (and good luck dealing with lifecycle issues).
  - llmslave2 9mo ago
    You can do it multiple ways. Like in go: cloj := func() { val := 1 return func(m string) { switch m { case "inc": val = val + 1 case "dec": val = val - 1 } } } () cloj("inc") In JS you can close upon state and return an object, which is essentially how classes work in the language. let cloj = (() => { let x = 0; return { inc: () => x++, dec: () => x-- } })() cloj.inc()
  - gpderetta 9mo ago
    a tuple of closures closing over the same object ('let over lambda') is equivalent to an interface.
  - antonvs 9mo ago
    > I guess closures in languages like Scheme can have multiple "methods"? At the language implementation level, Scheme-like closures only have one operation, which is the ability to apply them to arguments and thus evaluate them. But as a couple of the other replies show, a closure's code can be implemented as a dispatcher which handles multiple methods. That's not a language feature, just user code. I wrote the koan quoted above in 2003, a few years before Graydon Hoare started working on Rust. At the time, there weren't any "static" languages with built-in support for closures. Even Python had only had read-only closure support for a couple of years at that point - so those closures couldn't be used to implement mutation of closed-over variables. (Python didn't get mutable closures until around 2008.) Java only got closure support in version 8 around 2014. C++ 11 got closures in 2011. Of course you can implement dynamic-dispatching objects using closures in Rust or C++, but that's not going to be the equivalent of a statically-defined structure.
bonesss 9mo ago
In addition to the underlying domain (and I agree, it’s no coincidence that windowed GUI widgets are common in in OOP textbooks), there’s also overlapping spectrums of language expressiveness and object-orientedness to consider. The principle of least surprise, bad evil and scary techniques in general might be the orthodox, efficient and intuitive for maintainers in context. Templates in GUI frameworks versus business apps, for example.

flohofwoe 9mo ago

> For games? All the time. Hmm, but game objects is exactly the popular use case where traditional inheritance breaks down first and composition makes much more sense? That's why the whole Entity-Component idea came up decades ago (like in Unity, long before the more modern column-database-like ECS designs).

llmslave2 9mo ago
Entity systems still rely on inheritance as you typically have an Entity baseclass that all entities derive from. That's just a single level of inheritance. Unity does this through MonoBehavior. Unreal is more inheritance-heavy but developers typically subclass something like `Actor` to one level of additional inheritance beyond the Engine's subclasses. A lot of engines will have multiple superclasses behind a Entity class, but that's an implementation detail of the engine itself and to the game developer, it's treated as a single base class that is typically subclassed a single time for the entity itself. Even in ECS's you will often find inheritance. Some implementations have you inherit a Component struct, others will have the systems inherit a System class. I'm sure it's still used today in some engines and by some developers but the overwhelming opinion is that doing something like Entity -> Actor -> Monster -> Orc -> IceOrc is a bad idea. Instead it would be like class IceOrc : Entity { components {Health, Enemy, PlayerSeek, Position, etc} } Where each component is like class Health : Component { value = 100 } And yeah, they favour composition re. Components, it's just that the components tend to inherit from a Component class. But I would still call it composition!
- flohofwoe 9mo ago
  Yes there is some inheritance left in those composition-systems, but a single inheritance level is really more like implementing an interface.
  - llmslave2 9mo ago
    It is, but you get the benefit of shared behaviour and state. Like an Entity might have a Position, a reference to the World, the Screen, methods for interacting with other entities, etc. You don't get that from simply implementing an interface, although it's not difficult to pass those into the object. A common example I've seen is having every class extend an EventEmitter superclass. You could implement that as part of the interface but that becomes a ton of duplication. I think of it like this: If you model your domain as something like `A : B : C : D {}` you get all the problems of inheritance, when simply doing D { A; B; C; } gives you the same benefits without the problems. Doing `A : X {}, B : X {}, C : X {}` sidesteps most of the problems with inheritance but gives you some of the benefits as well.