5 ms·

Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.c

by smlckz 6y ago

Read the accepted answer to this question: https://stackoverflow.com/questions/2800964/benefits-of-prototypal-inheritance-over-classical https://stackoverflow.com/questions/2800964/benefits-of-prot...

searchableguy 6y ago
> @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.
- antigirl 6y ago
  How would you write a component based architecture like React has? New API has moved away from the classical syntax where it would ‘extend’ React component but I assumed it was still doing prototypal inheritance. Isn’t it better for memory to have some sort of inheritance?
  - mantap 6y ago
    Honestly these things are all variations on a theme in JavaScript. The language is flexible enough that you can write code in many different ways and they all end up being equivalently powerful. In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. It's a totally different beast to classical inheritance in Java that has such a bad reputation because it's such a straightjacket
    - gridlockd 6y ago
      The problem is that people don't realize how much of an anti-feature this sort of flexibility is. > In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. Yeah maybe, but please don't do that.
      - mantap 6y ago
        If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) Language flexibility doesn't obscure the readability of code. It enhances it. In a flexible language, unclear code is always programmer error, and programmer error is fixable. In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
        gridlockd 6y ago
        > If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) I don't find it shocking, I think it's a sign of immaturity. Been there, done that. > Language flexibility doesn't obscure the readability of code. It enhances it. Given a language without any sorts of constraints, any program can and will be written in any conceivable style. In design - not just programming language design - constraints are generally a good thing. > In a flexible language, unclear code is always programmer error, and programmer error is fixable. Virtually all errors are fixable in principle. In practice, there's a budget. Your clever and elegant but utterly idiosyncratic abstractions are costing me money in terms of getting people onboarded. > In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes) This is not a bad trade-off at all. A flexible language invites architecture astronauts to re-invent the concept of classes or modules over and over in slightly different ways. That's Javascript until ES6 and we're still suffering from it.
        smlckz 6y ago
        >> In design - not just programming language design - constraints are generally a good thing. The best example of that in programming language design I have seen is the V programming language. (https://vlang.io https://vlang.io) No global variables, no null/undefined/nil/None/... V is the only language I know in which variable shadowing is an error. (Do you know any other language with this feature/constraint?) And then I remember the handling of ''var''s in js and hoisting etc. ... sigh!
- gridlockd 6y ago
  > Author finally opened his eyes. The next level of enlightenment is figuring out that applied FP isn't that great either and to use whatever makes sense, wherever it makes sense.
  - searchableguy 6y ago
    That's a classical argument but it doesn't add anything ever other than pleasing everyone. It's a centerist opinion of programming. Sometimes opinions are great to get everyone on the same table even if for some usage, some things might not be appropriate.
    - gridlockd 6y ago
      > Sometimes opinions are great to get everyone on the same table I think opinions generally achieve the opposite of that. That said, if you're sitting at the table where everybody believes in FP, you should wholeheartedly apply FP principles - or find another table. That's part of "do what makes sense, where it makes sense". The really good thing about OOP though is that nobody really believes in it anymore. That opens up the opportunity to take some good ideas and insights and apply them undogmatically. FP has good ideas and insights as well, but it's more difficult to separate those from the cargo cult surrounding it.
- kazinator 6y ago
  > There's never a good reason to use inheritance. Looks rather like eyes closing to me.
  - skipants 6y ago
    Definitely agree with you. as much as I hate inheritance... never using it seems like a big leap.
    - kazinator 6y ago
      I hate being locked to single inheritance. Like, okay, we got the properties of foo; so that means we now absolutely cannot be a bar. It bugs me even if there is no plan to do that in the current program. By inheriting from foo, I'm enforcing the decision that this cannot be a bar, which could cause a problem to a future maintainer (maybe myself in six months). Java has single inheritance, which sucks; but it has multiple inheritance of interfaces at least, and good luck doing any serious work in Java without that being involved. (That is also designed that way in order to pander to implementation ease and certain run-time efficiencies; but has been turned into fallacious arguments like "multiple inheritance is bad ... unless it's interface inheritance"). Oh, and one problem with this prototype business is that in fact it is single inheritance (in the typical incarnations, at least; am I invoking a strawman)? It seems inescapable that supporting multiple inheritance under the prototype paradigm requires that we make a single new object out of two or more existing objects. But if objects are effectively just bags of properties (a.k.a. hash tables) it does seem easily doable. Make new empty object, stuff with properties of all argument objects, season to taste, return.
deleted 6y ago
[deleted]
kazinator 6y ago
1. It's simple. Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description. A prototype object system is barely one step above pretending that a hash table is an object. 2. It's powerful. It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this. 3. It leads to smaller, less redundant code. Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control. We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea. 4. It's dynamic and hence it's better for dynamic languages. This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic. Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method. Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs. Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.

by smlckz 6y ago

searchableguy 6y ago

> @s̮̦̩e̝͓c̮͔̞ṛ̖̖e̬̣̦t̸͉̥̳̼ It's been a while since I wrote this answer. My views have changed since I wrote it. Now, I believe that inheritance, both classical and prototypal, are bad and should be avoided at all costs. There's never a good reason to use inheritance. If you're writing object-oriented code then you should always prefer composition over inheritance. Even better, don't write object-oriented code. Embrace functional programming. Author finally opened his eyes.

antigirl 6y ago
How would you write a component based architecture like React has? New API has moved away from the classical syntax where it would ‘extend’ React component but I assumed it was still doing prototypal inheritance. Isn’t it better for memory to have some sort of inheritance?
- mantap 6y ago
  Honestly these things are all variations on a theme in JavaScript. The language is flexible enough that you can write code in many different ways and they all end up being equivalently powerful. In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. It's a totally different beast to classical inheritance in Java that has such a bad reputation because it's such a straightjacket
  - gridlockd 6y ago
    The problem is that people don't realize how much of an anti-feature this sort of flexibility is. > In JavaScript you have precise control over inheritance, you can specify your own algorithm for how class A inherits from classes B and C. Yeah maybe, but please don't do that.
    - mantap 6y ago
      If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) Language flexibility doesn't obscure the readability of code. It enhances it. In a flexible language, unclear code is always programmer error, and programmer error is fixable. In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes)
      - gridlockd 6y ago
        > If you find that shocking you would probably drop dead at seeing what Lisp programmers get up to with macros :) I don't find it shocking, I think it's a sign of immaturity. Been there, done that. > Language flexibility doesn't obscure the readability of code. It enhances it. Given a language without any sorts of constraints, any program can and will be written in any conceivable style. In design - not just programming language design - constraints are generally a good thing. > In a flexible language, unclear code is always programmer error, and programmer error is fixable. Virtually all errors are fixable in principle. In practice, there's a budget. Your clever and elegant but utterly idiosyncratic abstractions are costing me money in terms of getting people onboarded. > In an inflexible language, a lack of clarity can sometimes be unavoidable (e.g. java programmers forced to shoehorn everything into classes) This is not a bad trade-off at all. A flexible language invites architecture astronauts to re-invent the concept of classes or modules over and over in slightly different ways. That's Javascript until ES6 and we're still suffering from it.
        smlckz 6y ago
        >> In design - not just programming language design - constraints are generally a good thing. The best example of that in programming language design I have seen is the V programming language. (https://vlang.io https://vlang.io) No global variables, no null/undefined/nil/None/... V is the only language I know in which variable shadowing is an error. (Do you know any other language with this feature/constraint?) And then I remember the handling of ''var''s in js and hoisting etc. ... sigh!
gridlockd 6y ago
> Author finally opened his eyes. The next level of enlightenment is figuring out that applied FP isn't that great either and to use whatever makes sense, wherever it makes sense.
- searchableguy 6y ago
  That's a classical argument but it doesn't add anything ever other than pleasing everyone. It's a centerist opinion of programming. Sometimes opinions are great to get everyone on the same table even if for some usage, some things might not be appropriate.
  - gridlockd 6y ago
    > Sometimes opinions are great to get everyone on the same table I think opinions generally achieve the opposite of that. That said, if you're sitting at the table where everybody believes in FP, you should wholeheartedly apply FP principles - or find another table. That's part of "do what makes sense, where it makes sense". The really good thing about OOP though is that nobody really believes in it anymore. That opens up the opportunity to take some good ideas and insights and apply them undogmatically. FP has good ideas and insights as well, but it's more difficult to separate those from the cargo cult surrounding it.
kazinator 6y ago
> There's never a good reason to use inheritance. Looks rather like eyes closing to me.
- skipants 6y ago
  Definitely agree with you. as much as I hate inheritance... never using it seems like a big leap.
  - kazinator 6y ago
    I hate being locked to single inheritance. Like, okay, we got the properties of foo; so that means we now absolutely cannot be a bar. It bugs me even if there is no plan to do that in the current program. By inheriting from foo, I'm enforcing the decision that this cannot be a bar, which could cause a problem to a future maintainer (maybe myself in six months). Java has single inheritance, which sucks; but it has multiple inheritance of interfaces at least, and good luck doing any serious work in Java without that being involved. (That is also designed that way in order to pander to implementation ease and certain run-time efficiencies; but has been turned into fallacious arguments like "multiple inheritance is bad ... unless it's interface inheritance"). Oh, and one problem with this prototype business is that in fact it is single inheritance (in the typical incarnations, at least; am I invoking a strawman)? It seems inescapable that supporting multiple inheritance under the prototype paradigm requires that we make a single new object out of two or more existing objects. But if objects are effectively just bags of properties (a.k.a. hash tables) it does seem easily doable. Make new empty object, stuff with properties of all argument objects, season to taste, return.

deleted 6y ago

[deleted]

kazinator 6y ago

1. It's simple. Yes, to hack up, so what? Non-prototype object systems can also be written simply and in a small footprint, and have a reasonably small description. A prototype object system is barely one step above pretending that a hash table is an object. 2. It's powerful. It's not expressive of OOP concepts and creates spaghetti code. All OOP is monkey patching: make this object like that one, but patch this. 3. It leads to smaller, less redundant code. Because you're not properly specifying classes, which serve as an important guide to the structure of your program, and provide a locus of control. We can achieve smaller and less redundant code by identifying every function that is only called once and manually inlining it, so there is no name that is redundantly mentioned two places in the program. That doesn't mean it's a good idea. 4. It's dynamic and hence it's better for dynamic languages. This point is subtly fallacious. Dynamic languages also have non-prototype based object systems, which are also dynamic and good for those languages. There is good dynamic and there is bad dynamic. Under prototype object, it's hard to do certain important dynamic things like redefine the method of a class such that all objects of that class (existing instances) use the new method. Non-prototype objects systems in dynamic languages can easily support prototype-like mechanisms without those being the main mechanism of organization of OOP programs. Failing that, in any dynamic language that gives you hash tables, you can ignore the fine OOP system and do prototypes with hashes.