How it feels to learn JavaScript in 2016

Jordan Harband ljharb at gmail.com
Sun Nov 26 01:22:31 UTC 2017


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20171125/65a199a3/attachment.html>


More information about the es-discuss mailing list