typeof symbol (Was: Sept 19 TC39 Meeting Notes)

Herby Vojčík herby at mailbox.sk
Sat Sep 29 14:11:19 PDT 2012



Brendan Eich wrote:
> Herby Vojčík wrote:
>> So, symbols look to me more like primitives/atoms (that means, not an
>> object nor function) and so they should have their own typeof...
>
> That's progress, if you agree typeof aSymbol should not return "string"
> ;-).
>
> However, what you say about "I hold no subvalues, my identity is my
> value" can fit an empty frozen object too.
>
> Anyway if you feel strongly typeof should return "symbol" not "object"
> we have to face the dragons around the edge of the known typeof map.
> Fortunately IE shipped some in the known world. I could buy "symbol" but
> I'm also inclined toward "int64", "uint64", and other value-object
> typeof results in the future.

Not strongly. But philosophically they seems like kind of (unforgeable) 
primitives. Conceptually, they could be either fill objects (I can add 
properties to them and thus use them not only as unique symbols but also 
as holders/namespaces/communication channels) or their nature is "my 
identity is my only value".

Both are fine, but I think typeof should be "object" if it is the former 
(they are objects then), but should be "symbol" if the former (because 
then, they are atoms).

Frozen empty object can be created, and technically it has same 
properties, but it seems to me as an abuse of object. I'd like to see 
rise of use of symbols not only as unique (private) names, but also for 
other atom-like places, as a sentinels, for example (where such empty 
frozen objects were used before, or primitives like null or empty string).

> The hard thing is the non-zero risk of breaking some code by officially
> extending typeof, vs. the zero risk of using "object". The latter won't
> break any code that already might fail due to the full range of {null,
> pre-ES5 objects, frozen/sealed via ES5 API usage objects}.

It's political decision, others may say what they think. I formulated 
what I see conceptually, what would make me feel that the logic behind 
the ES6 is not so hairy (well, null :-/ but it can't be helped). Of 
course, there are pragmatic, technical decisions they may break the 
desire for beautiful systematics.

>
> /be

Herby


More information about the es-discuss mailing list