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
