4 ms·

ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that

by phpnode 12y ago

ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already.

chriswarbo 12y ago
I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in their code; especially library authors.
- phpnode 12y ago
  > those who don't use it are often forced to take it into account in their code; especially library authors. No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between: function Thing () {} Thing.prototype.greet = function () { alert("hello"); }; and class Thing { greet () { alert("hello"); } } They are the same, so it introduces no new traps for library authors.
  - antimagic 12y ago
    About the only thing that might be interesting to see is how constructor parameters are handled. With the prototyping system, I consider it to be a bug to initialize members in the constructor - if you always just call an 'init' method straight after construction (typically chained, much like in Objective C - var thing = new Thing().init(param); ) then protyping is very simple and does nothing surprising. It's only if you really really really want to have RAII that things become complicated...
rtpg 12y ago
Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all! If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.
- phpnode 12y ago
  > If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles. Sorry but that's total nonsense. For instance, node.js makes heavy use of classes, as does Backbone, Ember, React, etc
  - phpnode 12y ago
    To whoever downvoted me, am I wrong? Please explain.
    - Demiurge 12y ago
      Most of the time downvoting stands for 'Your comment hurts my feelings.' This comment will be very light gray ;D
- Demiurge 12y ago
  Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.
  - tel 12y ago
    Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful. * FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever. As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense.

by phpnode 12y ago

ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already.

chriswarbo 12y ago

I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in their code; especially library authors.

phpnode 12y ago
> those who don't use it are often forced to take it into account in their code; especially library authors. No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between: function Thing () {} Thing.prototype.greet = function () { alert("hello"); }; and class Thing { greet () { alert("hello"); } } They are the same, so it introduces no new traps for library authors.
- antimagic 12y ago
  About the only thing that might be interesting to see is how constructor parameters are handled. With the prototyping system, I consider it to be a bug to initialize members in the constructor - if you always just call an 'init' method straight after construction (typically chained, much like in Objective C - var thing = new Thing().init(param); ) then protyping is very simple and does nothing surprising. It's only if you really really really want to have RAII that things become complicated...

rtpg 12y ago

Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all! If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.

phpnode 12y ago
> If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles. Sorry but that's total nonsense. For instance, node.js makes heavy use of classes, as does Backbone, Ember, React, etc
- phpnode 12y ago
  To whoever downvoted me, am I wrong? Please explain.
  - Demiurge 12y ago
    Most of the time downvoting stands for 'Your comment hurts my feelings.' This comment will be very light gray ;D
Demiurge 12y ago
Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.
- tel 12y ago
  Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful. * FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever. As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense.