Re: es-discuss Digest, Vol 97, Issue 31

[Eric Elliott]

>
>5. Re: How to fix the `class` keyword (Allen Wirfs-Brock)
>
> One of those possible enhancement that has been talked about is to
> implicitly treat a [[Call]] of a class constructor as an implicit 'new',
> just like you are suggesting.
>

Doesn't this need to be configurable, and Brendan Eich suggested?
https://gist.github.com/ericelliott/1c6f451b2ed1b634c2f2

If implicit `new` is the only behavior, it blocks the factory refactor
path. https://gist.github.com/ericelliott/e994ee541d0ed365f5fd

If skipping the `new` treatment is the only behavior, it breaks backward
compatibility with constructors expecting the `new` treatment.

~ee
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: How to fix the `class` keyword (Brendan Eich)

[Eric Elliott]

>
>
> In case it helps, the idea mooted for ES7 is that you'd add a "call
> handler" to the class for when it is invoked without `new`:
>
>   class Point2D {
> constructor(x, y) { this.x = x, this.y = y; }
> [Symbol.call](x, y) { return new this.constructor(x, y); }
> ...
>   }
>
> I used `this.constructor`, but of course using `Point2D` directly is
> possible. In that case, subclasses would have to override the
> `[Symbol.call]` method, which seems undesirable and easily avoided as shown
> above.
>
> Bottom line, we don't want an implicit call handler in ES6. We need to get
> this right in ES7, and failing hard for now is the only way to be
> future-proof.
>
> /be
>

Thanks Brendan. This is very helpful indeed! Where can I learn more about
that solution?

I assume for backwards compatibility, this will not be default behavior, so
we're going to have to remember to use this boilerplate with every class if
we don't want them to be broken, right?

~ee
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

How to fix the `class` keyword

[Eric Elliott]

I've already posted this on my Medium blog here:
https://medium.com/@_ericelliott/how-to-fix-the-es6-class-keyword-2d42bb3f4caf

It seems inevitable that the `*class*` keyword in JavaScript is going to
catch on, but that’s a problem because it’s fundamentally broken in many
ways.

Now that it’s out there and people are using it, it seems like the only
logical way forward is to *try to make it better for everybody*.

In JavaScript, *any function can instantiate and return objects.* When you
do so without a constructor, it’s called a *factory function*. The new `
*class*` syntax *can’t compete with the power and flexibility of factories*
— specifically stamps, and object pools are not the only factory use-case.

There is a whole section on object construction in the GoF “Design
Patterns” book

which
exist only to get around the limitations of constructors and classes.

See also: Three Different Kinds of Prototypal OO.


The bottom line: *Class doesn’t give you any power* that isn’t already
supplied by *factory functions* and the *prototypal OO* built into the
language. All you’re doing when you create a class is opting into a *less
powerfull, less flexible mechanism* and *a whole lot of pitfalls and pain.*


Is there any hope that the `*class*` keyword will ever be useful? *Maybe.*
Why should we bother?


Why don’t we just create a lint rule and move on?

*The `class` keyword is creating a rift* in the JavaScript community. I for
one have plans to create an ESLint config that prohibits `*class*` and
share it as far and as wide as I can — and since I’m building a community
of JavaScript developers that currently includes ~40,000 people, that’s far
enough to have an impact.

*Classes could be useful*. What if we want to build abstractions on top of
it? What if we want to do more things in the language itself that could
benefit with `*class*` integration (such as built-in *traits*)?

*We could make these changes opt-in* by adding config to the class itself.
That would prevent breaking changes and hopefully make the whole community
happy. As it stands, we're just making people with classical inheritance
backgrounds happy -- *at least until they fall into one of the many
pitfalls ahead of them.*

*Shouldn’t the entire JavaScript community benefit from `class`?*
*How to Fix `class`*

   1. *Make class inheritance compositional* similar to the way stamps are
   composed.
   

In
   other words, change the behavior of `*extend*`, or *deprecate `extend`* and
   replace it with something like a *`compose` keyword* that can *compose
   any number of classes.*
   2. *Deprecate `new`. *`*new*` violates both the *substitution principle* and
   the *open / closed principle*. The `*new*` keyword is destructive
   because *it adds zero value to the language*, and it *couples all
   callers to the details of object instantiation*. If you start with a
   class that requires `*new*` (all classes in ES6) and you later decide
   you need to use a factory instead of a class, *you can’t make the change
   without refactoring all callers.* This is especially problematic for
   shared libraries and public interfaces, because *you may not have access
   to all of the code using the class.* You may think it doesn’t do any
   harm to just call a factory function with the `*new*` keyword, but the `
   *new*` keyword triggers behaviors that change what’s going on when the
   function is invoked. If you can’t count on the function to behave the same
   way for all callers, you can’t predict what the software will do. That’s
   bad.
   3. Make sure that *`class` obeys the substitution principle* when you
   switch from a class to a factory and vise verse. This is an important
   point, because if callers are counting on any behavior or property of a
   class, and you decide to change the implementation to a factory, you’ve
   just broken the calling code. Additionally, if callers are counting on the
   behavior of a factory, and you switch the implementation to a class, that’s
   similarly problematic, though as it stands, *there’s no good reason to
   switch from a factory to a class*.

The third point may be the most difficult, but if we can *catalog every
possible breaking change* here, there may be some hope for `*class*` in the
future, assuming we can get consistency baked into the language spec.

If we can’t fix these problems with `*class*`, we should push to *deprecate
the keyword entirely,* because as it exists today, *`class` is broken and
absolutely should not be used*

Re: Array.prototype.contains

[Eric Elliott]

According to the thread:

>* On Thu, Feb 23, 2012 at 3:15 PM, Erik Arvidsson <https://mail.mozilla.org/listinfo/es-discuss>>
*>* wrote:*

>* DOM4 added a new interface called DOMStringList for the sole reason
*>* that Array does not have contains. Before this the return type was an
*>* Array of Strings so we could use indexOf, map, forEach etc. Now that
*>* it is using a non Array we lost all of that.

> *We (WebKit) used to return a true JS Array (created by JSC or V8).


Author, "Programming JavaScript Applications" (O'Reilly)
http://ericleads.com/


On Wed, Mar 5, 2014 at 2:07 AM, David Bruant  wrote:

>  Le 05/03/2014 09:24, Eric Elliott a écrit :
>
> What ever happened to Array.prototype.contains? There's an old strawman
> for Array.prototype.has (
> http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has )
> that references this thread: (
> https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )
>
> Let's try to add it to the next meeting agenda
> https://github.com/tc39/agendas/pull/27
>
>
>   But it seems the thread fizzled out a couple years ago, and
> Array.prototype.contains didn't seem to make its way into ES6. That seems
> odd, since we do have String.prototype.contains, and it seemed like it was
> desirable for DOM.
>
> The DOM won't inherit from it directly, shall it?
>
>
>
>  It's also a standard utility function in several libraries.
>
>  Was it left out on purpose? If so, what was the justification?
>
> I predict code like this without it:
>
> ''.contains.call([1, 2, 3], 2);  // true
>
> .indexOf === -1 works today for this use case and will continue to.
> I'd be happy to see !~arr.indexOf(el) disappear in favor of a use of
> .contains() though.
>
> David
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Array.prototype.contains

[Eric Elliott]

What ever happened to Array.prototype.contains? There's an old strawman for
Array.prototype.has (
http://wiki.ecmascript.org/doku.php?id=strawman:array.prototype.has ) that
references this thread: (
https://mail.mozilla.org/pipermail/es-discuss/2012-February/020745.html )

But it seems the thread fizzled out a couple years ago, and
Array.prototype.contains didn't seem to make its way into ES6. That seems
odd, since we do have String.prototype.contains, and it seemed like it was
desirable for DOM. It's also a standard utility function in several
libraries.

Was it left out on purpose? If so, what was the justification?

I predict code like this without it:

''.contains.call([1, 2, 3], 2);  // true

- Eric

Author, "Programming JavaScript Applications" (O'Reilly)
http://ericleads.com/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Another switch

[Eric Elliott]

In practice, I find that everything converts nicely to a string when you
precede it with a ternary assignment.

I also find that when you do that, it's pretty trivial to control what
those strings are, which makes `hasOwnProperty` superfluous.

I haven't used a switch in JavaScript for quite a few years now, and I
don't miss it at all.

- Eric

Author, "Programming JavaScript Applications" (O'Reilly)
http://ericleads.com/


On Fri, Feb 21, 2014 at 10:26 AM, Rick Waldron wrote:

>
>
>
> On Fri, Feb 21, 2014 at 7:55 AM, Nick Krempel wrote:
>
>> Also only works when you're switching on something with a meaningful
>> conversion to string.
>>
>
> On 20 Feb 2014, at 21:20, Eric Elliott  wrote:
>
> > Object literals are already a great alternative to switch in JS:
> >
> > var cases = {
> >   val1:  function () {},
> >   val2: function () {}
> > };
> >
> > cases[val]();
>
>
> Right, this wouldn't work if the "case" wanted object references, but it
> would work nicely with Symbols.
>
> Rick
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Another switch

[Eric Elliott]

Object literals are already a great alternative to switch in JS:

var cases = {
  val1:  function () {},
  val2: function () {}
};

cases[val]();

Fall through is more trouble than it's worth, IMO.
On Feb 17, 2014 1:44 PM, "Giacomo Cau"  wrote:

>   -Messaggio originale-
> From: Brendan Eich
> Sent: Wednesday, February 12, 2014 2:00 AM
> To: Nathan Wall
> Cc: Giacomo Cau ; es-discuss@mozilla.org
> Subject: Re: Another switch
>
> Definitely good to see new languages being designed and implemented.
>
> JS is not going to break compatibility on the old fall-through behavior
> of switch, inherited from Java from C++ from C. All the C-like languages
> copy this flaw, because to do otherwise with the same keyword would be
> worse (confused users cross-training and -coding among languages would
> want our scalps), and IMHO using novel reserved words would be hardly
> better.
>
> /be
> > Nathan Wall 
> > February 11, 2014 at 3:21 PM
> > Hi Giacomo,
> >
> > Not sure whether this will be of interest to you, but I have been
> > working on a JS-derived language called Proto (still highly
> > experimental) which has a switch statement that works exactly as you
> > described:
> >
> > https://github.com/Nathan-Wall/proto/blob/master/docs/control/switch.md
> >
> > Perhaps you will at least find it interesting. :)
> >
> > Nathan
> >
>
> yes, so great it would be a pleasure to contribute :)
>
> the proposal doesn't want, by no means, to break the compability with the
> present syntax and/or semantics of the switch.
> At most, should be considered as an extension of current syntax with a
> consequential new semantics.
>
> the swith, as it is known, should anyhow be written as
>
> switch (...) {
> case ...: ...; break;
> case ...: ...; break;
> case ...: ...;
> case ...: ...; break;
> otherwise: ...
> }
>
> but, it could be handy to write the same thing with a slightly different
> syntax:
>
> switch (...) break {
> case ...: ...;
> case ...: ...;
> case ...: ...; continue;
> case ...: ...;
> otherwise: ...
> }
>
> Some break less, no new keyword, no incompatibility with past.
> Who shall use it, will know from the start that here, the continue will
> not lead him at the beginning of the first for or while that englobe the
> switch, but only at the following case.
>
>
> Then, willingly, we could also think that normal switch be desugared in
>
> switch (...) continue {
> case ...: ...; break;
> case ...: ...; break;
> case ...: ...;
> case ...: ...; break;
> otherwise: ...
> }
>
> with break and continue (except that between ')' and '{' ) that,
> obviously, continue as before.
> This isn't a must, it's just for my pleasure in finding regularity.
>
>
> At last, if we were to look for the burden of a new keyword, even better
>
> select (...) {
> case ...: ...;
> case ...: ...;
> case ...: ...; continue;
> case ...: ...;
> otherwise: ...
> }
>
> but I realize this could be a break point of the existing code and,
> onestly speaking, it is beyond my ability to evaluate.
>
>
> Anyhow, thanks for your attention.
>
>
> bye
>
> Giacomo Cau
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classical inheritance is obsolete

[Eric Elliott]

"That skeleton doesn’t even have to be a hierarchy, it could be a set of
classes."

Then you don't need `extends` or `super`.

- Eric


On Sun, Jun 30, 2013 at 4:42 PM, Axel Rauschmayer  wrote:

> To me, single inheritance has always been the skeleton on which I hang
> multiply inherited pieces. That skeleton doesn’t even have to be a
> hierarchy, it could be a set of classes.
> Maybe you simply need to write a mixin or trait library that works well
> with ES6 classes?
>
> Axel
>
> On Jul 1, 2013, at 0:22 , Eric Elliott  wrote:
>
> "Honest question: how can this problem not be solved via ES6 classes plus
> mixins? The original hierarchy already feels wrong. Why not create a
> super-class Animal, with sub-classes Human, Ape, Bird, Bee, Fish, Whale
> plus the mixins Walking, Flying, Swimming?"
>
> I completely agree with you, but in the real world we don't always have
> the benefit of knowing future requirements enough to create the correct
> design from the outset. Maybe the design was correct in the beginning
> (immagine a classification of species, instead of a classification of
> species capabilities)... and that's the problem with class - "so you go
> to re-implement them as mixins, but now you have to refactor all the
> animals that already rely on those features"
>
> "I also don’t see why refactoring is such a bad thing: as your knowledge
> of the problem domain increases, the structure of your program evolves."
>
> Small refactors are not a bad thing, but class hierarchies create tight
> coupling between child and parent classes (yes, even ES6 class, especially
> with super). In these situations, the dependencies are not always obvious,
> or direct, and they tend to ripple out far and wide, and are not easily
> aided by technology -- it's not a matter of replacing some variable names
> across your project -- it's a matter of reengineering these to deal with
> systemic changes in behavior.
>
> Mixins and other compositional reuse patterns don't create any tight
> coupling between child and parents, and much more easily provide for
> selective inheritance (I only want the banana, not the gorilla, banana, and
> entire jungle).
>
> - Eric
>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classical inheritance is obsolete

[Eric Elliott]

"Honest question: how can this problem not be solved via ES6 classes plus
mixins? The original hierarchy already feels wrong. Why not create a
super-class Animal, with sub-classes Human, Ape, Bird, Bee, Fish, Whale
plus the mixins Walking, Flying, Swimming?"

I completely agree with you, but in the real world we don't always have the
benefit of knowing future requirements enough to create the correct design
from the outset. Maybe the design was correct in the beginning (immagine a
classification of species, instead of a classification of species
capabilities)... and that's the problem with class - "so you go to
re-implement them as mixins, but now you have to refactor all the animals
that already rely on those features"

"I also don’t see why refactoring is such a bad thing: as your knowledge of
the problem domain increases, the structure of your program evolves."

Small refactors are not a bad thing, but class hierarchies create tight
coupling between child and parent classes (yes, even ES6 class, especially
with super). In these situations, the dependencies are not always obvious,
or direct, and they tend to ripple out far and wide, and are not easily
aided by technology -- it's not a matter of replacing some variable names
across your project -- it's a matter of reengineering these to deal with
systemic changes in behavior.

Mixins and other compositional reuse patterns don't create any tight
coupling between child and parents, and much more easily provide for
selective inheritance (I only want the banana, not the gorilla, banana, and
entire jungle).

- Eric
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classical inheritance is obsolete

[Eric Elliott]

"I don’t think you appreciate how hard it was to reach the consensus for
ECMAScript 6 classes (lots of incredibly long, incredibly passionate
discussions!)"

I do appreciate it, and I bit my tongue for much of it, but as the idea of
class in JavaScript has been catching on more in the last couple of years,
I'm starting to see the effects of that mental shift more and more in real
world code-bases, and the problems I thought I left in Java land more than
a decade ago are haunting me every day again in the workplace. The more my
coworkers ask about how to get around these problems, the more I'm
convinced that class in JavaScript is a really bad idea.

I understand that a lot of people have invested in it, but the number of
people who invested time in the design of the JavaScript language pales in
comparison to the number of people who will use it. And that's what
motivates me to speak out about it.

- Eric


On Sat, Jun 29, 2013 at 7:07 PM, Axel Rauschmayer  wrote:

> On Jun 29, 2013, at 20:12 , Eric Elliott  wrote:
>
> If I were advertising, there are better places to do it, and better ways.
> I feel like adding class to JS would be detrimental to the language and the
> users of the language, and I feel that the previous discussions on the
> topic did not make a strong enough argument against it.
>
> Let me try to paraphrase what you are criticizing about ECMAScript 6
> classes:
>
> 1. Single inheritance doesn’t always cut it, we need some kind of multiple
> inheritance (mixins/traits/...).
>
> 2. ES6 classes prevent mixins/traits/...
>
> 3. ES6’s implementation of single inheritance is ugly.
>
> 4. We have everything we need. Let’s all agree on a common, elegant
> library.
>
> Comments on these points:
>
> (1) I don’t think anybody disagrees with this point. That’s why
> mixins/traits/... are firmly on the roadmap for versions after ECMAScript
> 6. For one-dimensional taxonomies, single inheritance is perfectly
> adequate. If you have cross-cutting concerns, you can model them as mixins.
> There are many more interesting OOP mechanisms (before/after/around
> methods, cooperative methods, meta-object protocols, etc.). Thus, ES6
> classes are but the simplest possible first step.
>
> (2) ECMAScript 6 classes don’t prevent mixins. Certainly not in the
> future, but not even now – you can extend an object (instead of a function)
> and that object can be generated by your mixin library of choice:
>
> class SubClass extends mixin(SuperClass, Mixin1, Mixin2, ...) { ... }
>
> (3) In my opinion, that’s the most valid criticism of ES6 classes: They
> look like object exemplars, but desugar to function exemplars. That will
> probably sometimes confuse people. On the other hand, backward
> compatibility matters! And constructors are the most commonly used and most
> optimized inheritance mechanism that JavaScript currently has. With more
> configurability coming up in ES7 or later, it is also conceivable that at
> some point in the future, we’ll be able to switch to a different desugaring
> for classes (per module).
>
> (4) The JavaScript ecosystem suffers from a lot of NIH. If we couldn’t
> agree on a common library in the years since ECMAScript 5’s existence, it’s
> highly unlikely that it will ever happen. That’s why I think ES6 classes
> are so important: they enable us to exchange code between frameworks that,
> at the moment, have completely incompatible inheritance APIs.
> Object.observe helps, too, because it obviates the need for hacks to enable
> data binding. Similar to modules, I’m pretty sure we’d be incapable of
> agreeing on a common standard without ECMAScript 6.
>
> CONCLUDING THOUGHT:
> I don’t think you appreciate how hard it was to reach the consensus for
> ECMAScript 6 classes (lots of incredibly long, incredibly passionate
> discussions!). Would I have done classes differently? Yes. But the
> consensus enables us to have a solution that is good enough, which (IMO) is
> far better than having nothing.
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
>
> home: rauschma.de
> twitter: twitter.com/rauschma
> blog: 2ality.com
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classical inheritance is obsolete

[Eric Elliott]

"JS is a rich language that allows different styles of programming. Nothing
wrong with that."

What's wrong is that when we give people `class` and `extends`, books and
blog posts everywhere will begin to teach that this is how we do
inheritance in JavaScript, ignoring all the perils that go with them. The
default style will be a style that frequently leads developers down the
wrong path.

It is a pit of dispair, rather than a pit of success.
http://www.codinghorror.com/blog/2007/08/falling-into-the-pit-of-success.html

In contrast, we could give developers better sugar around mixins,
prototypes, and functional inheritance, giving them the same ease-of-use
that exists with the `class` keyword, without the dangers.

- Eric
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classical inheritance is obsolete

[Eric Elliott]

Brendan,

You seem to only be replying to the most recent comment in this thread, and
not considering the objections that I raised at the beginning of the
thread. My argument is that class isn't just a little bit of sugar. I
believe that counter to its goal, it will reduce programmer productivity by
causing code arthritis, duplication, and forcing refactors that would not
be needed if people instead leaned on mixins, functional inheritance, and
other compositional patterns that are already easy to implement in
JavaScript.

I further argue that a programming language has a UX, and good UX design
should involve creating a pit of success that users fall into. It is my
assertion that class is a pit of dispair, that so frequently leads people
down the path of wrong design that is *hard to fix* down the road, it
should not exist in the language at all.


"I get the sinking feeling that someone has had a bad time drinking too
much Java or C# OOP-booze and, in the manner of a reformed drunk, wants us
all to do things the hard way when making prototypal inheritance patterns
with constructors, static and prototype methods, |super|-done-by-hand, etc."

I don't want people to do things the hard way. I want us to give people
easier ways to use patterns that are less likely to lead people down the
path of poor OO design. I go into much more detail about the perils of
class in this Fluent talk: https://vimeo.com/69255635

All of those perils exist in the current ES6 class spec, not just the way
it's done in Java or C#. Yeah, I had a bad time with Java and C++ in the
90's, but I've been programming JavaScript web applications since the late
90's, and having a really good time of it, until popular libraries started
incorporating class-like patterns. I got over my Java hangover more than
ten years ago. The headache I have now is caused by people mimicking
class-like constructs in JavaScript, very similar to what ES6 intends to do.

Backbone making .extend() essentially a required mechanism has been
particularly problematic in several different code bases that I have been
involved in.

Unfortunately, the problem is that requirements change over the lifespan of
an application, and what start out as simple models frequently evolve into
complex models, where single-parent hierarchies fail. Eventually, all
single-parent hierarchies are wrong for new uses.

I know that JavaScript doesn't lose its dynamic nature when we add class,
but, to bring back an earlier example, say you start with:

Animal
* Walking
  * Human
  * Ape
* Flying
  * Bird
  * Bee
* Swimming
  * Fish
  * Whale

Now you need alligator and duck. Alligator clearly needs walking and
swimming, so you go to re-implement them as mixins, but now you have to
refactor all the animals that already rely on those features -- or you end
up reimplementing the functionality as mixins, and now you have the same
features in two different places -- a violation of DRY. This is the
duplication by necessity problem.

You have to refactor everything, or live with a design that is overly
complicated and error prone.


"I observe that many other JS hackers have no such negative hangover-like
reaction, and on the contrary say they could use a little sugar, and even a
bit of the strong stuff (e.g., small kernel extensions such as |super|) in
the punch."

It is my assertion that those same hackers would have an easier time if
we'd just give them better ways to work with prototypes, mixins, and
functional inheritance. For an example in code, see Stampit:
https://github.com/dilvie/stampit


More reading on the perils of class:

http://davidwalsh.name/javascript-objects (three part blog post by Kyle
Simpson)

http://en.wikipedia.org/wiki/Call_super - Super is a code smell


The gorilla/banana problem

"The problem with object-oriented languages is they’ve got all this
implicit environment that they carry around with them. You wanted a banana
but what you got was a gorilla holding the banana and the entire jungle." -
Joe Armstrong

This is a great description from "Design Patterns" (GoF) -

"Once the software has reached adolescence and is put into service, its
evolution is governed by two conflicting needs: (1) the software must
satisfy more requirements, and (2), the software must be more reusable. New
requirements usually add new classes and operations and perhaps whole class
hierarchies. The software goes through an expansionary phase to meet new
requirements. This can't continue for long, however. Evuntually the
software will become too inflexible and athritic for further change. The
class hierarchies will no longer match any problem domain. Instead they'll
reflect many problem domains, and classes will define many unrelated
operations and instance variables."

This never happened to me in JavaScript until I worked in code that used
things like John Resig's Simple Class Inheritance, and Backbone's
.extend(), rather late in my JavaScript career. But of course, we were
using objects and inh

Re:

[Eric Elliott]

If I were advertising, there are better places to do it, and better ways. I
feel like adding class to JS would be detrimental to the language and the
users of the language, and I feel that the previous discussions on the
topic did not make a strong enough argument against it.

- Eric
On Jun 29, 2013 9:05 AM, "Domenic Denicola" 
wrote:

>  FYI this thread honestly feels like you're trying to get more people to
> watch your video and use your library. I'm sorry not enough people are
> using/watching your stuff, but this mailing list isn't really the place to
> push it.
>
> On Jun 29, 2013, at 8:58, "Eric Elliott"  wrote:
>
>   Hi Alex,
>
> Your response is extremely vague. It doesn't seem to say more than "I
> think you're wrong. Oh, and lots of other people think you're wrong too."
>
> 1) Who are these "many" who disagree with the potential for harm? Can you
> cite some references?
>
> 2) Have you watched the talk? https://vimeo.com/69255635
>
> 3) Are there specific points that you disagree with?
>
> - Eric
>
>
> On Sat, Jun 29, 2013 at 7:11 AM, Alex Russell wrote:
>
>>
>> On 28 Jun 2013 19:31, "Eric Elliott"  wrote:
>> >
>> > I'm not here to discuss the mechanics of what class does. I'm just
>> saying we shouldn't do it in the spec.
>>
>> And many, including me, disagree with you: both in the potential for harm
>> and for reasons that are about our own codebases.
>>
>> > There are better alternatives that pose less threat to the JavaScript
>> ecosystem.
>> >
>> > A handful of libraries and JavaScript authors twisting prototypes to
>> make them less useful is one thing. Getting a blessing from on-high for
>> people to teach that it's "how to do inheritance in JavaScript" in teaching
>> materials is quite another thing.
>> >
>> > My arguments (and a few suggested alternatives) are in the video.
>> >
>> > If you're going to blow off what I have to say about it because you
>> don't have time to watch a video, I guess the conversation is over. =)
>> >
>> > - Eric
>> >
>> >
>> > On Fri, Jun 28, 2013 at 10:45 AM, Tab Atkins Jr. 
>> wrote:
>> >>
>> >> On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott 
>> wrote:
>> >> > I know this has been batted around already. I know everybody's
>> totally
>> >> > stoked about class sugar in ES6. I just wanted to register my
>> protest. I
>> >> > made my arguments in this talk at Fluent:
>> >> >
>> >> >
>> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
>> >> >
>> >> > I'm already seeing nasty codebase arthritis creep into JavaScript
>> projects
>> >> > thanks to things like Backbone.View.extend() being essentially
>> mandatory.
>> >> >
>> >> > Providing sugar to extend classes in JavaScript proper is like
>> officially
>> >> > sanctioning that nonsense.
>> >> >
>> >> > I'm not the only one who feels that way. Here's an excerpt from one
>> viewer's
>> >> > comment on my presentation:
>> >> >
>> >> > "I think this will only get worse with ES6 and I am rather upset
>> about it.
>> >> > While 'class' will be elective of course, I can only imagine more
>> and more
>> >> > libraries adopting the ES6 class pattern, and then we will wind up
>> facing
>> >> > the same set of challenges that exist in the Java world."
>> >> >
>> >> >
>> >> > In my opinion, the clamoring for class in JavaScript is because
>> JavaScript
>> >> > tries to hide prototypes, rather than make it easy to deal with them.
>> >> > Instead of class, we should let library authors continue to
>> experiment with
>> >> > other inheritance patterns in JavaScript. Here's an example:
>> >> >
>> >> > https://github.com/dilvie/stampit
>> >> >
>> >> > We do need a bit more object sugar in JS, but I think we should wait
>> for
>> >> > some patterns to gain a foothold in the wild, and only when popular
>> patterns
>> >> > emerge and have time to be tested and proven to be well-thought-out
>> and a
>> >> > valuable addition (unlike Backbone's .extend

Re:

[Eric Elliott]

"it could be quickly refactored as following"

Except that a bunch of animals already depend on Swimming, and now they all
need to be refactored as well, or you have to duplicate Swimming
functionality in more than one place, and then you have unexpectedly
divergent implementations across different animals (maybe a bug in one type
of swimming animal that doesn't exist in another, or bugs in both, you fix
it in one place, think it's fixed everywhere, only to discover later that
it wasn't.)

This is the famous unexpected divergence problem that arises from single
ancestor class inheritance... so even if you start out using class
inheritance, it can be problematic to switch to mixins and similar
strategies down the road.

- Eric


On Fri, Jun 28, 2013 at 7:41 PM, Claude Pache wrote:

>
>
> Le 29 juin 2013 à 00:14, Eric Elliott  a écrit :
>
> 
>
> I saw a recent example of one of the problems with single-ancestor
> inheritance in a talk. I wish I could remember which one. The illustrations
> were great:
>
> Animal
>   - Walking
> - Monkey
> - Human
>   - Flying
> - Bird
> - Bee
>   - Swimming
> - Fish
> - Whale
>
> Now we need alligator and duck.
>
>
> Interesting challenge! It may be hard to resolve in some languages, but in
> JavaScript, you merely need some imagination. Given:
>
> ```js
> class Flying extends Animal {
> // implementation of Flying
> }
>
> class Swimming extends Animal {
> // implementation of Swimming
> }
> ```
>
> it could be quickly refactored as following (I assume that the
> implementation of Swimming is sufficiently well-written; otherwise some
> amendments in its implementation might be needed):
>
> ```js
> class Flying extends Animal {
> // implementation of Flying
> }
>
> function addSwimming(Animal) {
> class Swimming extends Animal {
> // implementation of Swimming
> }
> return Swimming
> }
>
> var Swimming = addSwimming(Animal)
>
> var FlyingSwimming = addSwimming(Flying)
>
> class Duck extends FlyingSwiming { }
> ```
>
> (It is true that `Duck instanceof Swimming` doesn't hold; however,
> duck-typing forbids the use of `instanceof` and even any typelike-check.)
>
> Note how JavaScript remains dynamic, even in the face of the
> ES6-class-sugar.
>
>
> —Claude
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re:

[Eric Elliott]

Hi Alex,

Your response is extremely vague. It doesn't seem to say more than "I think
you're wrong. Oh, and lots of other people think you're wrong too."

1) Who are these "many" who disagree with the potential for harm? Can you
cite some references?

2) Have you watched the talk? https://vimeo.com/69255635

3) Are there specific points that you disagree with?

- Eric


On Sat, Jun 29, 2013 at 7:11 AM, Alex Russell  wrote:

>
> On 28 Jun 2013 19:31, "Eric Elliott"  wrote:
> >
> > I'm not here to discuss the mechanics of what class does. I'm just
> saying we shouldn't do it in the spec.
>
> And many, including me, disagree with you: both in the potential for harm
> and for reasons that are about our own codebases.
>
> > There are better alternatives that pose less threat to the JavaScript
> ecosystem.
> >
> > A handful of libraries and JavaScript authors twisting prototypes to
> make them less useful is one thing. Getting a blessing from on-high for
> people to teach that it's "how to do inheritance in JavaScript" in teaching
> materials is quite another thing.
> >
> > My arguments (and a few suggested alternatives) are in the video.
> >
> > If you're going to blow off what I have to say about it because you
> don't have time to watch a video, I guess the conversation is over. =)
> >
> > - Eric
> >
> >
> > On Fri, Jun 28, 2013 at 10:45 AM, Tab Atkins Jr. 
> wrote:
> >>
> >> On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott 
> wrote:
> >> > I know this has been batted around already. I know everybody's totally
> >> > stoked about class sugar in ES6. I just wanted to register my
> protest. I
> >> > made my arguments in this talk at Fluent:
> >> >
> >> >
> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
> >> >
> >> > I'm already seeing nasty codebase arthritis creep into JavaScript
> projects
> >> > thanks to things like Backbone.View.extend() being essentially
> mandatory.
> >> >
> >> > Providing sugar to extend classes in JavaScript proper is like
> officially
> >> > sanctioning that nonsense.
> >> >
> >> > I'm not the only one who feels that way. Here's an excerpt from one
> viewer's
> >> > comment on my presentation:
> >> >
> >> > "I think this will only get worse with ES6 and I am rather upset
> about it.
> >> > While 'class' will be elective of course, I can only imagine more and
> more
> >> > libraries adopting the ES6 class pattern, and then we will wind up
> facing
> >> > the same set of challenges that exist in the Java world."
> >> >
> >> >
> >> > In my opinion, the clamoring for class in JavaScript is because
> JavaScript
> >> > tries to hide prototypes, rather than make it easy to deal with them.
> >> > Instead of class, we should let library authors continue to
> experiment with
> >> > other inheritance patterns in JavaScript. Here's an example:
> >> >
> >> > https://github.com/dilvie/stampit
> >> >
> >> > We do need a bit more object sugar in JS, but I think we should wait
> for
> >> > some patterns to gain a foothold in the wild, and only when popular
> patterns
> >> > emerge and have time to be tested and proven to be well-thought-out
> and a
> >> > valuable addition (unlike Backbone's .extend(), which is causing lots
> of
> >> > problems in the real world), only THEN should the idea be blessed by
> the
> >> > specification.
> >> >
> >> > Is class a good idea in JavaScript? I say, prove it. In fact,
> anything that
> >> > can have a reference implementation should be proven - not just by
> >> > implementing it to see if it can work, but if it can be polyfilled (or
> >> > something like it could be polyfilled), put it in a library and see
> if it
> >> > catches on before you add it to the spec, and everybody starts to
> write
> >> > about it in their "new JavaScript features" posts.
> >> >
> >> > So far, NO IMPLEMENTATION of class in JavaScript has become a de-facto
> >> > standard. I think we should set the bar a little higher where a new
> feature
> >> > could actually cause damage to the language ecosystem.
> >> >
> >> > Unti

Re:

[Eric Elliott]

"Gang of Four says prefer composition to inheritance, not avoid inheritance
 altogether."

That wasn't such an easy choice in Java or C++. It's a down-right trivial
choice in JavaScript.

"As you suggest near the end of your last reply, you can use composition or
injection with any of those constructors in the inheritance hierarchy to
add or override behavior."

When you're working in an established codebase, it's much harder to go
against the grain of momentum than your reply suggests.

For example, project x had been using Backbone.View.extend(),  and has a
6-generation class hierarchy. Now the root level's constructor function is
doing something that the youngest child needs to override -- but every
other ancestor relies on that functionality, and the youngest relies on
functionality of its ancestors in-between. (This was an actual situation in
an actual codebase with over 100,000 lines of client-side JavaScript).

Since all the descendant classes relied on the implementation of the
ancestors (through .super() calls), the mess was not easy to detangle. It
wasn't simply a matter of grafting some stuff on to an object after the
fact. Single-parent hierarchies make it hard to do selective inheritance.
(I refer you again to the gorilla banana problem).

If the code had relied less on sub-classing views, and more on mixins, this
problem never would have come up.

"Rely on an interface, not an implementation" - violated by sublassing and
super().

"If the argument is against the class extends super syntax in ES6, I agree
it's not necessary in ES.  But as others have pointed out, it's an opt-in
feature that we won't be forced to use"

See the pit of dispair vs pit of success argument I made in my last reply.

"I haven't seen coupling as a *problem* withinheritance per se so much as
that a constructor is doing *any* work at all - by which I mean
side-effects"

I could not agree more about avoiding side-effects, but inheritance (even
without instantiation side-effects) still suffers from other problems.
Notably the specialization problem of single-ancestor inheritance, which
leads to collections of similar objects with unexpectedly divergent
properties. Composition / mixins give you easy selective inheritance. (See
also, the gorilla banana argument).

Yes, you can selectively inherit by copying properties, but not if your
constructors are used for private state (which is often a good thing -- it
allows you to hide implementation details so that users of your API can
program to your interface, not your implementation).

If you're using patterns like the ones found in Stampit, you don't have
that problem, either.

- Eric


On Fri, Jun 28, 2013 at 5:07 PM, david kaye  wrote:

> Eric -
>
>
> On class-based inheritance
>
> Gang of Four says prefer composition to inheritance, not avoid inheritance
> altogether.
>
> As you suggest near the end of your last reply, you can use composition or
> injection with any of those constructors in the inheritance hierarchy to
> add or override behavior. It does not follow that we should never use an
> inheritance hierarchy for generally shared or default behavior.
>
> If the argument is against the class extends super syntax in ES6, I agree
> it's not necessary in ES.  But as others have pointed out, it's an opt-in
> feature that we won't be forced to use (big thank you to everyone for
> supporting backward compatibility).  As David Bruant noted, some prefer not
> to use Object.create() and just use new function() instead (I'm one of them
> - I'm guilty).
>
> If the argument is against them in all cases, we still have to use care
> with mixins (see ActiveRecord for an extreme case) and interfaces, etc., as
> even a change to a trait or interface can have consequences downstream.
>
>
> Out here in Userland
>
> I've seen the same pathology you describe in several codebases - it also
> happens with CSS descendant rules and id selectors, !important rules and
> inline style attributes to override them *this one time*.
>
> But, I haven't seen coupling as a *problem* with inheritance per se so
> much as that a constructor is doing *any* work at all - by which I mean
> side-effects - which is an argument for using Object.create - which I now
> note with irony.
>
> The one thing that saved us from dread of *OMG we have to re-visit
> everything* has been reliance on unit tests - test-driven-development, or
> test-during-development really does reduce the fear of later confusion -
> but that's another discussion entirely.
>
>
> Sorry for preaching to the choir and/or ruffling feathers
>
> DFKaye
>
>
>
>   --
>  *From:* David Bruant 
> *To:* Eric Elliott 
> *Cc:*

Re:

[Eric Elliott]

"The rest of JavaScript remains. ES6 classes are just a sugar on top of the
ES5 runtime concepts (objects with [[Prototype]], [[Get]], [[Set]], etc.)."

When class is blessed by the spec, many people will interpret it as the
default way that objects are created and inheritance is done in JavaScript.

I see that as a sad outcome for the JavaScript community. Perhaps
temporarily convenient for people from a classical background --
temporarily, but in the long run, they are not served by it.

My question to you is this:

Does class bring value to JavaScript that is currently missing?


"People already think in a broken way when it comes to software. Software
is hard. Lots of people model data inside strings. I believe this is a much
bigger problem than classes. What's the solution for stringly typed code?"

What you want for a good UX (yes, programming languages have UX) is a pit
of success -- where people do the right thing by default. A `class` keyword
gives people a pit of dispair... where it's very easy to fall into doing
the wrong thing by default. Instead of class sugar, we need sugar around
less problematic forms of code reuse.

http://www.codinghorror.com/blog/2007/08/falling-into-the-pit-of-success.html

There's good reason that class hierarchy problems have always been so
common in C++ and Java, but were almost non-existent in JavaScript until
very recently -- and it's not just because people are only just now using
JavaScript to build large applications. Some of us have been doing that
since the 90's.

JavaScript's prototypal inheritance is a pit of success. Class is a pit of
dispair.

"Classes and the single-ancestor pattern are limited in the sort of objects
they can model. Animals are such an example.
But you can model other simpler things that don't have properties that
cross over. Classes can work for these cases."

Yes, classes are limited. Unfortunately, most developers don't see the
limitations coming, and that's the crux of the problem. Counting on them to
foresee problems coming when requirements are constantly changing is a
losing strategy.

Can you give me examples of where `class` adds enough value to make up for
all its shortcomings, or is it really just a bit of sugar to help
developers avoid typing a little more?

"By that argument, we can remove maybe 70% of the JS built-ins."

Except that most built-ins in JavaScript add significant value *without*
adding significant danger that can cost developers months in refactors and
rewrites.

"Among expert-enough people, using classes may become the sign of simple
models (when there is no need for specialization) or simple specialization
patterns. That's a good thing. It's not big, but it's a good thing."

A very simple factory abstraction can do the same -- and it doesn't require
"expert-enough people", and it's much more flexible and capable (see
stampit, for example https://github.com/dilvie/stampit ). Again - without
the danger that comes with `class`.

"Does the ES6 super has the same issue than the Java one? I really don't
feel I have enough expertise in the matter to say yet."

Yes. `super()` is problematic because you have to remember to call it, or
remember not to call it, or even think about whether or not you should be
calling it. If there are instantiation details that need to be handled,
they should be hooked so that they happen automatically. There are several
good patterns for that. stampit() automatically adds init methods to a
callback queue and guarantees that they all run automatically. The
developer doesn't need to think about it. Init hooks can completely replace
the need for `super()`. I haven't called `super()` on anything since ...
2010?

And I code large JavaScript applications every day for a living. Feels
great to be liberated from it.

"choosing class or not class is rarely the heart of the problem when you've
mis-modeled your software."

It's a lot harder to mismodel your software when your objects are composed,
rather than relying on brittle class inheritance structures. That's the
whole reason you should favor composition over class inheritance.

Want to fix class in ES6? Call it something else, replace extends with
mixin, remove super, and allow any number of init functions to be added,
rather than relying on a single constructor.

"No, the problem is when people limit the way they think about software
through this only one paradigm. If this paradigm is here alongside others,
I don't see the problem. People have the choice."

JavaScript is confusing enough to people without adding `class`. Sometimes
giving people more choice is a bad thing:
http://www.amazon.com/The-Paradox-Choice-More-Less/dp/0060005696

- Eric


On Fri, Jun 28, 2013 at 3:55 PM, David Bruant  wrote:

>  Le 29/06/2013 00:14, Eric Elliott

Re:

[Eric Elliott]

"I'm not very interested in the classical vs prototypal battle. Both are
barely different mechanisms of specialization."

I couldn't disagree with that more strongly. Just because you can mimic
class easily with prototypes doesn't make them "barely different". If
you're not interested in that conversation, you can safely ignore
everything else I have to say, because you've effectively blown it off. Stick
your head in the sand if you like. The problem doesn't go away.

"I'm however very interested if you could take a look at the current
proposal and tell if you can pin down how the current proposal makes
classes harmful for code maintainability."

Basically, my argument is that the whole paradigm of a class with a single
ancestor, and any mention of that ancestor in the implementation of the
child (referring to the parent in the constructor, for instance), is
fundamentally flawed and problematic. `extends` harms code maintainability
by virtue of creating the brittle hierarchy / gorilla-banana problem I've
already described.

The problem isn't how it's done in JavaScript or ES6. The problem is that
it's done at all.

Class gets people thinking in a fundamentally broken paradigm for good OO
design.

I saw a recent example of one of the problems with single-ancestor
inheritance in a talk. I wish I could remember which one. The illustrations
were great:

Animal
  - Walking
- Monkey
- Human
  - Flying
- Bird
- Bee
  - Swimming
- Fish
- Whale

Now we need alligator and duck.

I understand that JavaScript doesn't restrict you from doing things like
mixins as well... but when you're 14 months into a project, and THEN you
have to add the alligator, suddenly you're mixing paradigms in ways that
diverge significantly from the style of the rest of the code base. At this
point, the code is already arthritic and brittle. Fitting these things in
at this point is a lot less trivial.

If you're relying on things like super in the rest of the code, how does
the new stuff properly invoke the constructors of multiple ancestors which
are designed to be single ancestors?

I can tell you how I've seen these situations handled in the real world,
virtually everywhere the problem has cropped up (pretty much everywhere
that class was relied on heavily). Massive refactors. Code rewrites. Lots
of wasted time.

Class sugar might save developers a few keystrokes today, but it will come
back to bite them hard later. Lots of people are paying for Backbone's
.extend().

If it added value, that would be one thing. But it doesn't actually do
anything that couldn't have been done just by replacing it with a
constructor that produced objects that could be passed into those
constructors to produce new objects. I have seen the problems in code at
Adobe, at Tout, and at BandPage (my last three jobs, that all used
Backbone).

The problem isn't with Backbone's particular implementation. I had the same
problems in C++, Java, and with John Resig's Simple Inheritance in
JavaScript.

The problem isn't with the ES6 implementation. It's the whole paradigm.

- Eric


On Fri, Jun 28, 2013 at 2:27 PM, David Bruant  wrote:

>  Hi Eric,
>
> Le 28/06/2013 19:42, Eric Elliott a écrit :
>
> I know this has been batted around already.
>
> Has it? :-p
>
>
>  I know everybody's totally stoked about class sugar in ES6. I just
> wanted to register my protest. I made my arguments in this talk at Fluent:
>
>
> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
>
> Adding the class keyword into JavaScript does not mean adding all the
> constructs that Java has and all the problems that come along. Given the
> *current* ES6 class proposal, what issues do you see that would affect code
> maintainability?
>
>
>  I'm already seeing nasty codebase arthritis creep into JavaScript
> projects thanks to things like Backbone.View.extend() being essentially
> mandatory.
>
> Don't use Backbone?
> Can you expand on an example of what you call "nasty codebase arthritis"
> using Backbone?
>
>
>  Providing sugar to extend classes in JavaScript proper is like
> officially sanctioning that nonsense.
>
> I'm not the only one who feels that way. Here's an excerpt from one
> viewer's comment on my presentation:
>
> "I think this will only get worse with ES6 and I am rather upset about
> it. While 'class' will be elective of course, I can only imagine more and
> more libraries adopting the ES6 class pattern, and then we will wind up
> facing the same set of challenges that exist in the Java world."
>
> ES6 classes will desugar at runtime into JavaScript objects as we know
> them. How 

Re:

[Eric Elliott]

I've already invested significant time in trying to shed more light on this
topic. In my book, in that video, in blog posts, and now here. Take your
pick.

The cliff notes for the lazy (with sketchnotes!)

What I want to say has been said many times before: class inheritance
causes problems that do not even need to exist in JavaScript. The Gang of
Four considered this so important, that they made it one of two principles
which are a central theme in the "Design Patterns Book"... but even the
first principle is related, so I'll start there:

"Program to an interface, not an implementation",

If you need a reference to the parent class in the implementation of the
child class (the part that is expressed in the code of the language user),
that is a violation of that principle. That is why "super" is considered to
be a code smell.  http://martinfowler.com/bliki/CallSuper.html

and "Favor composition over class inheritance."

The reason for that is that deep inheritance hierarchies are too tightly
coupled (child to parent), and too dependent on parent implementation (see
above). These problems cause code arthritis as projects mature and you
begin to inherit from sub-classes. Eventually that leads inevitably to
brittleness, and the  famed gorilla banana problem.

"The problem with object-oriented languages is they’ve got all this
implicit environment that they carry around with them. You wanted a banana
but what you got was a gorilla holding the banana and the entire jungle." -
Joe Armstrong, "Coders at Work"

Debugging such structures can be challenging. Changing them can force
large, time consuming refactors, and in some cases, complete project
rewrites. I've seen this happen in the real world again-and-again. Mostly
in C++ and Java.

When I came to JavaScript in the late 90's, it seemed like there was some
relief from that. I just didn't see things like that happening very much...
despite being involved in JavaScript-heavy serious applications for almost
all of my career Until Backbone caught on and made .extend() the
defacto way to reuse code in a very popular library. Then suddenly
everybody started subclassing in JavaScript like it was a brand new idea.

Then I started seeing those problems I thought we'd left behind resurface
in real-world applications for companies producing apps with millions of
users. Serious problems with major code bases in the wild... because people
were running with a pattern that was never a good idea.

It is a particularly bad idea in JavaScript primarily because using it is
actually harder than using the better alternatives that already exist
natively (notably a single prototype (not a userland chain), and dynamic
object extension, which makes mixin implementations trivial). My argument
is that it should *stay harder to implement*.

Not only do we not need class, what we have is much easier, much more
flexible, and dramatically less problematic. Some great alternatives to
classes include modules (particularly those that export functions), factory
functions, object literals, Object.create(), and simple dynamic object
extension. You can combine all these and create some neat sugar that
doesn't involve single-ancestor inheritance, tight coupling between parent
and child, and encouraging users to think in a broken paradigm.

More reading (if you can find the time):

Sketchnotes - http://instagram.com/p/Z6ocvmRJSf/
Slideshow source - https://github.com/dilvie/fluent-prototypal-oo

Blog post -
http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/

Different author, similar message -
http://davidwalsh.name/javascript-objects (3 parts)

- Eric Elliott


On Fri, Jun 28, 2013 at 11:40 AM, Tab Atkins Jr. 
 wrote:

> On Fri, Jun 28, 2013 at 11:31 AM, Eric Elliott  wrote:
> > I'm not here to discuss the mechanics of what class does. I'm just
> saying we
> > shouldn't do it in the spec. There are better alternatives that pose less
> > threat to the JavaScript ecosystem.
> >
> > A handful of libraries and JavaScript authors twisting prototypes to make
> > them less useful is one thing. Getting a blessing from on-high for
> people to
> > teach that it's "how to do inheritance in JavaScript" in teaching
> materials
> > is quite another thing.
>
> It is how you do (single) inheritance in JS.  In your OP, you say "I
> think we should wait for some patterns to gain a foothold in the
> wild".  Single inheritance via prototype chains is an immensely
> popular pattern for this kind of thing.  You do qualify your statement
> by saying we should wait for *good* patterns, but single inheritance
> is perfectly good for some things, and adequate for quite a bit else.
> There are certainly better patterns, but none of them have gotten wide
> trac

Re:

[Eric Elliott]

I'm not here to discuss the mechanics of what class does. I'm just saying
we shouldn't do it in the spec. There are better alternatives that pose
less threat to the JavaScript ecosystem.

A handful of libraries and JavaScript authors twisting prototypes to make
them less useful is one thing. Getting a blessing from on-high for people
to teach that it's "how to do inheritance in JavaScript" in teaching
materials is quite another thing.

My arguments (and a few suggested alternatives) are in the video.

If you're going to blow off what I have to say about it because you don't
have time to watch a video, I guess the conversation is over. =)

- Eric


On Fri, Jun 28, 2013 at 10:45 AM, Tab Atkins Jr. wrote:

> On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott  wrote:
> > I know this has been batted around already. I know everybody's totally
> > stoked about class sugar in ES6. I just wanted to register my protest. I
> > made my arguments in this talk at Fluent:
> >
> >
> http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/
> >
> > I'm already seeing nasty codebase arthritis creep into JavaScript
> projects
> > thanks to things like Backbone.View.extend() being essentially mandatory.
> >
> > Providing sugar to extend classes in JavaScript proper is like officially
> > sanctioning that nonsense.
> >
> > I'm not the only one who feels that way. Here's an excerpt from one
> viewer's
> > comment on my presentation:
> >
> > "I think this will only get worse with ES6 and I am rather upset about
> it.
> > While 'class' will be elective of course, I can only imagine more and
> more
> > libraries adopting the ES6 class pattern, and then we will wind up facing
> > the same set of challenges that exist in the Java world."
> >
> >
> > In my opinion, the clamoring for class in JavaScript is because
> JavaScript
> > tries to hide prototypes, rather than make it easy to deal with them.
> > Instead of class, we should let library authors continue to experiment
> with
> > other inheritance patterns in JavaScript. Here's an example:
> >
> > https://github.com/dilvie/stampit
> >
> > We do need a bit more object sugar in JS, but I think we should wait for
> > some patterns to gain a foothold in the wild, and only when popular
> patterns
> > emerge and have time to be tested and proven to be well-thought-out and a
> > valuable addition (unlike Backbone's .extend(), which is causing lots of
> > problems in the real world), only THEN should the idea be blessed by the
> > specification.
> >
> > Is class a good idea in JavaScript? I say, prove it. In fact, anything
> that
> > can have a reference implementation should be proven - not just by
> > implementing it to see if it can work, but if it can be polyfilled (or
> > something like it could be polyfilled), put it in a library and see if it
> > catches on before you add it to the spec, and everybody starts to write
> > about it in their "new JavaScript features" posts.
> >
> > So far, NO IMPLEMENTATION of class in JavaScript has become a de-facto
> > standard. I think we should set the bar a little higher where a new
> feature
> > could actually cause damage to the language ecosystem.
> >
> > Until Backbone came along and made .extend() the default way to create
> any
> > Backbone object, it was very easy for a JavaScript programmer to spend an
> > entire career having never extended from an existing class. And that was
> a
> > good thing.
>
> Lots and *lots* of code already uses "the class pattern" is JS,
> because the class pattern is nothing more than:
>
> function Foo(){...}
> Foo.prototype = ...;
> Foo.prototype.method1 = function(){...}
>
> The class syntax just makes this super-common idiom easier to read and
> write.
>
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[no subject]

[Eric Elliott]

I know this has been batted around already. I know everybody's totally
stoked about class sugar in ES6. I just wanted to register my protest. I
made my arguments in this talk at Fluent:

http://ericleads.com/2013/06/classical-inheritance-is-obsolete-how-to-think-in-prototypal-oo/

I'm already seeing nasty codebase arthritis creep into JavaScript projects
thanks to things like Backbone.View.extend() being essentially mandatory.

Providing sugar to extend classes in JavaScript proper is like officially
sanctioning that nonsense.

I'm not the only one who feels that way. Here's an excerpt from one
viewer's comment on my presentation:

"I think this will only get worse with ES6 and I am rather upset about it.
While 'class' will be elective of course, I can only imagine more and more
libraries adopting the ES6 class pattern, and then we will wind up facing
the same set of challenges that exist in the Java world."


In my opinion, the clamoring for class in JavaScript is because JavaScript
tries to hide prototypes, rather than make it easy to deal with them.
Instead of class, we should let library authors continue to experiment with
other inheritance patterns in JavaScript. Here's an example:

https://github.com/dilvie/stampit

We do need a bit more object sugar in JS, but I think we should wait for
some patterns to gain a foothold in the wild, and only when popular
patterns emerge and have time to be tested and proven to be
well-thought-out and a valuable addition (unlike Backbone's .extend(),
which is causing lots of problems in the real world), only THEN should the
idea be blessed by the specification.

Is class a good idea in JavaScript? I say, prove it. In fact, anything that
can have a reference implementation should be proven - not just by
implementing it to see if it can work, but if it can be polyfilled (or
something like it could be polyfilled), put it in a library and see if it
catches on before you add it to the spec, and everybody starts to write
about it in their "new JavaScript features" posts.

So far, NO IMPLEMENTATION of class in JavaScript has become a de-facto
standard. I think we should set the bar a little higher where a new feature
could actually cause damage to the language ecosystem.

Until Backbone came along and made .extend() the default way to create any
Backbone object, it was very easy for a JavaScript programmer to spend an
entire career having never extended from an existing class. And that was a
good thing.

$.02
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss