it may be standard-operating-procedure to sub-class builtin arrays in
other languages. but it becomes awkward in javascript when time comes
around to serializing/reconstructing the custom array-type while
baton-passing it around frontend<->backend<->database via JSON.
On 11/3/17, Andrea Giammarchi <andrea.giammar...@gmail.com> wrote:
> I agree with everything else you said but since you mentioned the word
> "misinformed" I'd like to improve this misleading sentence:
>
>> It's 99% sugar over the existing prototype-based model
>
> This has been one of the most misunderstood and undertaken parts of ES6.
>
> Classes are *not* just sugar, thinking about classes as just sugar that can
> be replicated on ES5 is FUD and even if I've pointed out Babel
> documentation has a wrong description of classes it's still there and 99%
> of developers believe classes are like that, just sugar over prototypal
> inheritance.
>
> This is so wrong that TypeScript fails with the most basic extend:
>
> ```js
> class List extends Array { method() {} }
>
> (new List) instanceof List; // false
> (new List).method(); // throws because it's not a List so no method
> ```
>
> To simulate ES2015 classes you need `Reflect.construct`, unavailable in
> ES5.
> Polyfilling Reflect.construct with ES5 features is not enough: you need
> Symbols too.
>
> Symbols are technically impossible to polyfill (i've gone very close, yet
> not a perfect poly).
> Symbols are needed to keep the instance so that in a transpiled world:
>
> ```js
> (new List).slice() instanceof List; // true
> ```
>
> Most developers that went for classes have broken code out of the box
> thanks to transpilers and yet at the end of 2017 we keep writing that ES
> classes are just sugar on top of ES5.
>
> We should stop starting from this ML to keep spreading this wrong
> information.
>
> Thank you all for your understanding.
>
> Regards
>
>
>
>
>
>
>
> On Fri, Nov 3, 2017 at 4:49 AM, Isiah Meadows <isiahmead...@gmail.com>
> wrote:
>
>> Honestly, this entire thread reads as partially misinformed,
>> borderline trollbait. These kinds of questions and thoughts should
>> really be asked directly (and a bit more respectfully) to TC39
>> representatives and/or put in blog posts wherever. es-discuss is
>> primarily about language design, and although the subject implies it's
>> about the language's design in the abstract, I'm not convinced the
>> content and responses really are.
>>
>> 1. Claims of a language "civil war" don't belong on this list, and are
>> objectively false. Yes, there's disagreement, but even TC39 members
>> aren't exactly in agreement here - consider the difference between
>> Lodash/Ecmarkdown (Domenic Denicola) and Ecmarkup (Brian Terlson).
>> Please take that into account.
>> 2. Yes, there are multiple idiomatic uses of JavaScript, but it's
>> large enough you can carve out a subset and be done with it. You don't
>> like classes? Don't use them. You don't like arrow functions? Don't
>> use them. You don't like `array.map`? Don't use it. Just because they
>> exist doesn't obligate you to use them, and they don't hurt you in any
>> way if you don't. Also, complaints of a person's or group's choice of
>> idiom do *not* belong on this list whatsoever. Leave that crap to a
>> private message, a blog post (if it's a group), or whatever.
>> 3. JavaScript "classes" are not technically class-based OOP, and TC39
>> members have acknowledged this in blog posts. It's 99% sugar over the
>> existing prototype-based model, just with easier native subclassing.
>> You could in theory replicate this in the rest of the language with a
>> combination of `Object.defineProperty`, `Object.setPrototypeOf`,
>> `new.target`, and existing ES5.
>> -----
>>
>> Isiah Meadows
>> m...@isiahmeadows.com
>>
>> Looking for web consulting? Or a new website?
>> Send me an email and we can get started.
>> www.isiahmeadows.com
>>
>>
>> On Thu, Nov 2, 2017 at 4:32 PM, doodad-js Admin <dooda...@gmail.com>
>> wrote:
>> >
>> > -----Original Message-----
>> > From: Claude Petit [mailto:p...@webmail.us]
>> > Sent: Thursday, November 02, 2017 4:24 PM
>> > To: 'kai zhu' <kaizhu...@gmail.com>; 'es-discuss' <
>> es-discuss@mozilla.org>
>> > Subject: RE: javascript vision thing
>> >
>> > For mostly real OOP under JS, please see my project (doodad-js). But I
>> can't warranty its future without a custom language because nobody on
>> TC39
>> want to works along-side with me on that project, and they are making
>> their
>> own supposed "classes" which are not.
>> >
>> > -----Original Message-----
>> > From: kai zhu [mailto:kaizhu...@gmail.com]
>> > Sent: Wednesday, November 01, 2017 11:43 PM
>> > To: es-discuss <es-discuss@mozilla.org>
>> > Subject: javascript vision thing
>> >
>> > any thoughts? i'll break the ice with a quora question i recently
>> answered
>> >
>> > quora question:
>> >> Why is JavaScript so hated?
>> >
>> > answer posted:
>> >>the primary reason is because traditional oop skills gained from
>> c#/c++/java/python/etc translate poorly to javascript.
>> >>
>> >>in javascript, class-instantiated objects are inferior to
>> >> plain-objects,
>> because plain-objects come with JSON.stringify/JSON.parse baked-in, while
>> classes require needless extra serialization/deserialization routines
>> which
>> can easily double your codebase or more (as real-world javascript-code is
>> heavily i/o based). i would say many people burn-out from
>> frontend-programming because they can’t cope with debugging all the i/o
>> edge-cases serializing/deserializing their custom classes.
>> >>
>> >>javascript and frontend-programming is essentially about efficiently
>> managing the program-state like a baton, constantly passing it
>> back-and-forth between the browser’s ui and various backend-servers /
>> persistent-storage. plain json-objects utilizing idiot-proof
>> JSON.stringify/JSON.parse, are naturally better at this baton-passing
>> business than writing classes with custom serializers.
>> >
>> >
>> >
>> > there's currently a civil war going on in frontend-development, between
>> those who don't want to deal with writing extra class-based
>> serializers/deserializers and those who do. these 2 different design
>> patterns have incompatible styleguides that often break web-projects when
>> people try to mix-and-match both together. i don't have a simple
>> solution
>> to this issue, but tc39 should be made aware of it as they try to
>> formulate
>> a javascript vision that doesn't alienate frontend-development.
>> >
>> > -kai
>> >
>> >
>> >
>> > ---
>> > This email has been checked for viruses by AVG.
>> > http://www.avg.com
>> >
>> > _______________________________________________
>> > 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
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
