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 <ljh...@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 <kaizhu...@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.pa...@gmail.com> wrote: >> > >> >> Le 25 nov. 2017 à 16:03, kai zhu <kaizhu...@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@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
