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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to