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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >>> > >>> >> Le 25 nov. 2017 à 16:03, kai zhu <[email protected]> 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 >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
