How it feels to learn JavaScript in 2016

Alexander Jones alex at weej.com
Sun Nov 26 19:13:59 UTC 2017


They’re not even *objects*, let alone regular objects! :)

Making every new addition to the language be a subtype of object just
creates a worse language. Given the constraints and requirements it was the
right choice to make symbol a new primitive. Technically it “broke the
web”, like literally every new change to the language. But that’s not as
black and white as people make it out to be, by using such a catchy phrase.

typeof: officially subject to extensions.

Alex

On Sun, 26 Nov 2017 at 01:23, Jordan Harband <ljharb at gmail.com> wrote:

> Except that they're not regular objects; and if they'd done that, there'd
> just be the same potential problems with code naively written to accept an
> object (since Symbols are primitives, they don't have persistent
> properties, for example).
>
> Code that's written as if things will never change is brittle; "paranoid"
> code isn't over-engineered, it's simply *engineered* to handle change
> robustly.
>
> On Sat, Nov 25, 2017 at 5:30 PM, kai zhu <kaizhu256 at gmail.com> wrote:
>
>> claude, mature nodejs database drivers with frozen business logic for
>> stability reasons are examples of libraries that you are asking to
>> change whenever tc39 decides to expand typeof's on a whim which may
>> break them.
>>
>> the maintainers of sqlite3 for example have stated its in maintennance
>> mode (https://github.com/mapbox/node-sqlite3/issues/870), and all
>> commits for the past 2 years have dealt exclusively with its build
>> process so it can successfully compile with each nodejs release.
>>
>> i write database code myself.  what was my reaction to the
>> introduction of the 'symbol' typeof?  annoyance at trying to figure
>> out what pathological use-case a user might want to pass a 'symbol'
>> type to the database.  i imagine mongodb / mysql / sqlite3 maintainers
>> are equally annoyed with trying to figure that out.  if tc39 had
>> treated symbols as a regular 'object' type, then we wouldn't have that
>> problem, and the current undefined behavior when its encountered in db
>> drivers.
>>
>>
>> On 11/26/17, Claude Pache <claude.pache at gmail.com> wrote:
>> >
>> >> Le 25 nov. 2017 à 16:03, kai zhu <kaizhu256 at gmail.com> a écrit :
>> >>
>> >> i disagree.  you can write more maintainable and cleaner code with the
>> >> premise typeof's will never change again (and give a one-time pass for
>> >> symbols), instead of over-engineered paranoid code that it *may*
>> >> change again in the future.
>> >>
>> >
>> > It is the responsibility of the programmer to write *forward-compatible*
>> > code, i.e., code that does not make assumptions that are *likely* to
>> break
>> > in the future. For instance, one can *reasonably* think that the domain
>> of
>> > the `typeof` operator may expand.
>> >
>> > Naturally, the programmer should be smart enough in order to make the
>> > difference between paranoia and common sense: this is part of the art of
>> > programming.
>> >
>> > —Claude
>> >
>> >
>> _______________________________________________
>> 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/20171126/5c079715/attachment-0001.html>


More information about the es-discuss mailing list