3 ms·

Prototype-based OO is one of those concepts that sounds good, but it's just not what's actually needed in practice. Class-based OO just happens to be more effec

Prototype-based OO is one of those concepts that sounds good, but it's just not what's actually needed in practice. Class-based OO just happens to be more effective and useful when dealing with real-world problems. I don't think it's a problem with developers not understanding prototype-based OO; they do. It's just that they run into situations time and time again where class-based OO is a better option. Yet since JavaScript doesn't (yet) offer proper class-based OO functionality, developers needing or desiring such functionality are forced to implement it themselves. As anyone who has worked on any sizable, multi-developer JavaScript code base will surely know, there are many different approaches to simulating proper class-based OO in JavaScript. The maintenance headaches this causes are very real. The direction of the JavaScript current is just flat out wrong. It's not that developers should stop swimming against it; they're going in the right direction. The current itself should be reversed so that it aides the developers in the direction they want to go, rather than continually ramming against them.

tantalor 14y ago
> The maintenance headaches this causes are very real. Problems tend to occur when developers don't agree on code conventions. This has nothing to do with JavaScript or OOP.
- seanmcdirmid 14y ago
  How quickly we forget the Treaty of Orlando. http://dl.acm.org/citation.cfm?id=62144 http://dl.acm.org/citation.cfm?id=62144 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.482&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55....
  - pekk 14y ago
    considering that I apparently have to pay in order to read it (first link)...
    - seanmcdirmid 14y ago
      The second link provides a converted PDF copy for free.
nadaviv 14y ago
> It's just that they run into situations time and time again where class-based OO is a better option Can you give an example of such situation? My experience with prototype-based inheritance is quite different - I find that it can do everything that class-based inheritance can do, and more.
- tracker1 14y ago
  What's funny, is I tend to deal directly with raw JS objects as models, then use them against modules/functions. Rarely do I ever do inheritance, or reference this.* except when dealing with monad-like utilities such as jQuery or MomentJS. My life is much happier this way, it's effective and it works... Yes, it's much closer to a C-like way of dealing with libraries, but without all the messy issues like pointer logic or memory management. People need to stop trying to shove JS's triangle into a OO's round hole.
mtrimpe 14y ago
You might like working in GWT or Dart better then. I for one quite like being able to mix in other objects but exclude some properties/methods while still understanding what's actually happening under the hood without needing a Haskell-level type system.
- coldtea 14y ago
  >You might like working in GWT or Dart better then. Because one single feature (the above offering native classes) trumps stuff like browser support, libraries, or awkward development environment etc, right? Or he could continue to work with JS, with a class based system, either ad-hoc (as 99% of JS developers use), or built in ES6.
  - mtrimpe 14y ago
    We were talking about swimming against the stream or not. In those two languages the author's preferred programming style would be considered going with the stream. ES6 sounds great since it would offer the best of both worlds, but it's going to take quite a while before you'll be able to do your everyday development in ES6.
    - coldtea 14y ago
      >We were talking about swimming against the stream or not. In those two languages the author's preferred programming style would be considered going with the stream. Yes, but then you have to swim against other streams, like the languages not being mainstream, needing a translation layer ton run in the browser, etc etc.

tantalor 14y ago

> The maintenance headaches this causes are very real. Problems tend to occur when developers don't agree on code conventions. This has nothing to do with JavaScript or OOP.

seanmcdirmid 14y ago
How quickly we forget the Treaty of Orlando. http://dl.acm.org/citation.cfm?id=62144 http://dl.acm.org/citation.cfm?id=62144 http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55.482&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.55....
- pekk 14y ago
  considering that I apparently have to pay in order to read it (first link)...
  - seanmcdirmid 14y ago
    The second link provides a converted PDF copy for free.

nadaviv 14y ago

> It's just that they run into situations time and time again where class-based OO is a better option Can you give an example of such situation? My experience with prototype-based inheritance is quite different - I find that it can do everything that class-based inheritance can do, and more.

tracker1 14y ago
What's funny, is I tend to deal directly with raw JS objects as models, then use them against modules/functions. Rarely do I ever do inheritance, or reference this.* except when dealing with monad-like utilities such as jQuery or MomentJS. My life is much happier this way, it's effective and it works... Yes, it's much closer to a C-like way of dealing with libraries, but without all the messy issues like pointer logic or memory management. People need to stop trying to shove JS's triangle into a OO's round hole.

mtrimpe 14y ago

You might like working in GWT or Dart better then. I for one quite like being able to mix in other objects but exclude some properties/methods while still understanding what's actually happening under the hood without needing a Haskell-level type system.

coldtea 14y ago
>You might like working in GWT or Dart better then. Because one single feature (the above offering native classes) trumps stuff like browser support, libraries, or awkward development environment etc, right? Or he could continue to work with JS, with a class based system, either ad-hoc (as 99% of JS developers use), or built in ES6.
- mtrimpe 14y ago
  We were talking about swimming against the stream or not. In those two languages the author's preferred programming style would be considered going with the stream. ES6 sounds great since it would offer the best of both worlds, but it's going to take quite a while before you'll be able to do your everyday development in ES6.
  - coldtea 14y ago
    >We were talking about swimming against the stream or not. In those two languages the author's preferred programming style would be considered going with the stream. Yes, but then you have to swim against other streams, like the languages not being mainstream, needing a translation layer ton run in the browser, etc etc.