How it feels to learn JavaScript in 2016

kai zhu kaizhu256 at gmail.com
Sun Nov 26 19:54:49 UTC 2017


neither is null really an object, which for all practical purpose is
treated like a primitive, but the precedent was set to make it an
object.  symbol changed that precedent.

> typeof: officially subject to extensions.
we agree to disagree.  my opinion is introducing more types will only
make things that were simple more complicated.

-kai

On 11/27/17, Alexander Jones <alex at weej.com> wrote:
> 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
>>
>


More information about the es-discuss mailing list