3 ms·

Anyone who inherits from a class and accidentally overrides a method is a hopeless case or a newbie needing basic review from a senior dev. The bugs are on the

by micv 11y ago

Anyone who inherits from a class and accidentally overrides a method is a hopeless case or a newbie needing basic review from a senior dev. The bugs are on them. They can either test that their inheritence works, learn from the mistake, or they can piss off and find a new career emptying bins, flipping burgers, or whatever they fancy that doesn't involve making sure that what they just did will work beyond the immediate function.

overgard 11y ago
> Anyone who inherits from a class and accidentally overrides a method is a hopeless case or a newbie needing basic review from a senior dev That's a pretty harsh stance. I don't mean to be a jerk, but how much professional experience do you have? Even in good code bases there are frequently complicated hierarchies with non-obvious dependencies that are very easy to screw up even by people who know what they're doing. Good teams find ways of automating the checking on these things so that they can spend their time thinking about other problems, or avoiding the complication altogether, rather than blaming the victim.
- micv 11y ago
  I'm a decade in. I know what you mean about complex hierachies, but inheritence is a very, very dangerous tool; you either take the time to review the results, or you suffer the consequences. That's where the review by senior developers comes in. You learn or you don't. Who would want to work with devs who don't?
  - Jweb_Guru 11y ago
    I do, because I don't consider people's ability to deal with the vagaries of inheritance a valuable skill when you can just avoid it with effectively no negative consequences. Of course, to clarify, it's not really possible to avoid in languages like Java, where it is more or less mandatory due to the design of its standard library (unless you avoid that too, which is a considerably worse idea), but you can still keep your own CODE clean with liberal use of `final` and interfaces. Personally, I'm consistently baffled when programmers like yourself, who have come to appreciate that "inheritence [sic] is a very, very dangerous tool," continue to defend it so vigorously. If it offered really powerful or unique advantages, sure--but if you take a hard at what it actually provides, it's just syntactic sugar and a performance "optimization" (thin pointers) that's usually pessimal compared to other approaches. The downsides are significant and well-known (as mentioned above, Liskov substitution being undecidable is one consequence, but there are plenty of others). There's no point in making life harder for ourselves.
Tloewald 11y ago
It's much less obvious than you think. In many cases safely overriding a method requires correctly in invoking the inherited method, and failing to do so can cause subtle problems.
josephlord 11y ago
I'm more concerned with the case of someone overriding a method deliberately but without being aware of all the consequences.

by micv 11y ago

overgard 11y ago

> Anyone who inherits from a class and accidentally overrides a method is a hopeless case or a newbie needing basic review from a senior dev That's a pretty harsh stance. I don't mean to be a jerk, but how much professional experience do you have? Even in good code bases there are frequently complicated hierarchies with non-obvious dependencies that are very easy to screw up even by people who know what they're doing. Good teams find ways of automating the checking on these things so that they can spend their time thinking about other problems, or avoiding the complication altogether, rather than blaming the victim.

micv 11y ago
I'm a decade in. I know what you mean about complex hierachies, but inheritence is a very, very dangerous tool; you either take the time to review the results, or you suffer the consequences. That's where the review by senior developers comes in. You learn or you don't. Who would want to work with devs who don't?
- Jweb_Guru 11y ago
  I do, because I don't consider people's ability to deal with the vagaries of inheritance a valuable skill when you can just avoid it with effectively no negative consequences. Of course, to clarify, it's not really possible to avoid in languages like Java, where it is more or less mandatory due to the design of its standard library (unless you avoid that too, which is a considerably worse idea), but you can still keep your own CODE clean with liberal use of `final` and interfaces. Personally, I'm consistently baffled when programmers like yourself, who have come to appreciate that "inheritence [sic] is a very, very dangerous tool," continue to defend it so vigorously. If it offered really powerful or unique advantages, sure--but if you take a hard at what it actually provides, it's just syntactic sugar and a performance "optimization" (thin pointers) that's usually pessimal compared to other approaches. The downsides are significant and well-known (as mentioned above, Liskov substitution being undecidable is one consequence, but there are plenty of others). There's no point in making life harder for ourselves.

Tloewald 11y ago

It's much less obvious than you think. In many cases safely overriding a method requires correctly in invoking the inherited method, and failing to do so can cause subtle problems.

josephlord 11y ago

I'm more concerned with the case of someone overriding a method deliberately but without being aware of all the consequences.