Eric Elliott eric at ericleads.com
Sat Jun 29 08:58:15 PDT 2013


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 <slightlyoff at gmail.com> wrote:

>
> On 28 Jun 2013 19:31, "Eric Elliott" <eric at ericleads.com> 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. <jackalmage at gmail.com>
> wrote:
> >>
> >> On Fri, Jun 28, 2013 at 10:42 AM, Eric Elliott <eric at ericleads.com>
> 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 at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130629/4036d802/attachment-0001.html>


More information about the es-discuss mailing list