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 brit
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 (http
> Le 25 nov. 2017 à 16:03, kai zhu 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
On Sat, Nov 25, 2017 at 6:09 AM, kai zhu wrote:
> introducing the new typeof Symbol() === 'symbol' does break
> backwards compatibility with many es5 libraries that default to
> 'object' type if typeof is not 'boolean', 'number', 'string',
> 'function', or 'undefined'.
Which ones, **specifically*
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.
On 11/25/17, Oriol _ wrote:
> It was kind of obvious that che
It was kind of obvious that checking whether some value is an object by
ensuring that it's not any of the existing primitives would stop working if a
new primitive was added, which effectively happened with symbols. If some
library used that, I think it is to blame. Instead, I would recommend so
6 matches
Mail list logo
