Eric Elliott eric at ericleads.com
Sat Jun 29 11:12:17 PDT 2013


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" <domenic at domenicdenicola.com>
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" <eric at ericleads.com> 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 <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
>> >
>>
>
>   _______________________________________________
> 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/0fce569e/attachment.html>


More information about the es-discuss mailing list