`typeof null` is `"object"` for entirely historical implementation reasons,
not because things that don't fit the existing primitive list are
automatically `object`. Adding a new typeof `symbol` doesn't change a
precedent, because there was no such precedent. I understand that it's not
what you want, but that doesn't make it the wrong choice for the language.
If Symbols had been made typeof `"object"`, we'd have way more people on
here complaining about the exact opposite expectation that code like this
would work, where they assumed that `object` meant something that could
have properties added to it.
```
function addState(obj) {
if (typeof obj !== "object" || obj === null) throw new Error("State can
only be added to objects");
Object.defineProperty(obj, "state", {value: ""});
}
```
for instance if it were `"object"` instead, this would pass the library's
check and then throw because you can't define properties on a symbol,
instead of the nice error that the library author intended.
Adding additional typeof results also allows developers to write code
defensively. A dev could absolutely write
```
switch(typeof foo) {
case "undefined":
case "object":
case "number":
case "string":
case "boolean":
// handle normally
break;
default:
throw new Error(`Unexpected value with ${typeof foo}`);
}
```
to enforce their assumptions about type, and give the user helpful feedback
if new types are added in the future. If Symbol had been added as
`"object"`, there's is no way for developers to do this. Someone can guess
"maybe a new typeof will be added", but they would be super unlikely to
guess that a new object type would be added that didn't behave like any
other thing with typeof `"object".
At the end of the day, a new data type is always going to break assumptions
made somewhere, independent of whether there is a new `typeof` result or
not, and if that's already the case, adding a new typeof is much more
consistent with the types already in the language because Symbols do not
behave like normal objects.
I can't tell from what you've said so far, is your complaint that a new
`typeof` result was added, or is it that Symbols aren't actual objects? If
the complaint is entirely about `typeof` then I feel like my above comments
mostly make that clear, but if your issue is just that they should have
conceptually been objects, then I don't feel like you've made it clear why
that would be better than a new primitive (independent of typeof).
On Sun, Nov 26, 2017 at 11:54 AM, kai zhu <kaizhu...@gmail.com> wrote:
> 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 <a...@weej.com> 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 <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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
