4 ms·

'Need' is a big word. One 'needs' very few things. Software has actually been written in assembly, so what do we actually 'need'? Answer to both questions is y

by cjfd 4y ago

'Need' is a big word. One 'needs' very few things. Software has actually been written in assembly, so what do we actually 'need'? Answer to both questions is yes. When I read something like this I find the 'one size fits all' dogmatism disturbing. So, maybe someone somewhere created a class hierarchy that was needlessly complex. Now apparently the pendulum needs to swing all the way to the other side and all of inheritance is bad. I hear that lots of people are cutting themselves incidentally with knives. Shall we forbid them? In programming people don't seem to be able to settle on the middle ground, the pendulum always needs to swing to the extremes apparently. An example where implementation inheritance is beneficial? I have a calculation that depends on quite a few parameters. The calculation can be done from the application code but part of the calculation is rather expensive and is only done once every so often. So, I put the parameters of the calculation in a class, inherit another class from that the the application uses and that can do cheap calculations. I inherit another class that does the complicated part of the calculation. All in all three classes so not very complicated. The disadvantage with making the parameter class a member is that the code gets littered with indirection like 'data->param1' all over the place. This is much nicer.

zozbot234 4y ago
> The disadvantage with making the parameter class a member is that the code gets littered with indirection like 'data->param1' all over the place. This is much nicer. Isn't that a rather trivial concern? Implementation inheritance is not "much nicer" than delegation, the opposite in fact is the case. It adds a dispatch step to all calls to virtual methods (including calls that are private to implementations at any level of your 'hierarchy') that is not what you would want in most cases. Which in turn means your entire class hierarchy has to be analyzed as a single, highly-coupled program module; it's quite literally impossible to understand portions of it in isolation.
- cjfd 4y ago
  I find readability one of the most important properties of code. As the saying goes 'code is more often read then written'. Also, we have all seen where disregarding readability leads us, namely the java language, where one gets the impression that every java programmer is being paid in proportion to the number of characters they type. Any single step that leads us from readable code to typical java code may seem like a minor issue but in the end one ends up with code where the championship of large distance scrolling can be attained just in order to find out what is in a class. In cases I was describing readability really takes a bit hit. It is a bit like writing the abc-formula and having to write (- data->b +/- sqrt(pow(data->b, 2) - 4 * data->a * data->c ) / (2 * data->a). Being able to write (- b +/- sqrt(pow(b, 2) - 4 * a * c) / (2 * a) is so much nicer. Actually, the three classes I described by themselves do not need any virtual methods. But I was skimping on details a bit. There actually is a fourth class that is being used to mock the application facing class and that causes some virtual methods to be necessary.
cyber_kinetist 4y ago
By the way, Jai (which is a language currently being developed and is beta) has a “using” keyword which allows you to import the scope of the struct in normal functions, which looks like: do_something :: (using data: Data, arg: int) { field1 = field2 + arg … } Which lets you get rid of the annoying data.field1 and data.field2 indirection. I really wish more languages implement this feature…
- Jtsummers 4y ago
  Common lisp has had that for ages too, though you specify which slots you are interested in and possibly rename them (useful when you have multiple instances of the same class or classes with common slot names). http://clhs.lisp.se/Body/m_w_slts.htm http://clhs.lisp.se/Body/m_w_slts.htm http://clhs.lisp.se/Body/m_w_acce.htm#with-accessors http://clhs.lisp.se/Body/m_w_acce.htm#with-accessors

by cjfd 4y ago

zozbot234 4y ago

> The disadvantage with making the parameter class a member is that the code gets littered with indirection like 'data->param1' all over the place. This is much nicer. Isn't that a rather trivial concern? Implementation inheritance is not "much nicer" than delegation, the opposite in fact is the case. It adds a dispatch step to all calls to virtual methods (including calls that are private to implementations at any level of your 'hierarchy') that is not what you would want in most cases. Which in turn means your entire class hierarchy has to be analyzed as a single, highly-coupled program module; it's quite literally impossible to understand portions of it in isolation.

cjfd 4y ago
I find readability one of the most important properties of code. As the saying goes 'code is more often read then written'. Also, we have all seen where disregarding readability leads us, namely the java language, where one gets the impression that every java programmer is being paid in proportion to the number of characters they type. Any single step that leads us from readable code to typical java code may seem like a minor issue but in the end one ends up with code where the championship of large distance scrolling can be attained just in order to find out what is in a class. In cases I was describing readability really takes a bit hit. It is a bit like writing the abc-formula and having to write (- data->b +/- sqrt(pow(data->b, 2) - 4 * data->a * data->c ) / (2 * data->a). Being able to write (- b +/- sqrt(pow(b, 2) - 4 * a * c) / (2 * a) is so much nicer. Actually, the three classes I described by themselves do not need any virtual methods. But I was skimping on details a bit. There actually is a fourth class that is being used to mock the application facing class and that causes some virtual methods to be necessary.

cyber_kinetist 4y ago

By the way, Jai (which is a language currently being developed and is beta) has a “using” keyword which allows you to import the scope of the struct in normal functions, which looks like: do_something :: (using data: Data, arg: int) { field1 = field2 + arg … } Which lets you get rid of the annoying data.field1 and data.field2 indirection. I really wish more languages implement this feature…

Jtsummers 4y ago
Common lisp has had that for ages too, though you specify which slots you are interested in and possibly rename them (useful when you have multiple instances of the same class or classes with common slot names). http://clhs.lisp.se/Body/m_w_slts.htm http://clhs.lisp.se/Body/m_w_slts.htm http://clhs.lisp.se/Body/m_w_acce.htm#with-accessors http://clhs.lisp.se/Body/m_w_acce.htm#with-accessors