Relax -- it's es-discuss.
I wrote "Among the no-symbol proposals", which you of course read
correctly and knew excluded and allowed for a yes-symbol trump card. I
still want symbols.
/be
Tab Atkins Jr. <mailto:[email protected]>
September 26, 2013 3:50 PM
On Thu, Sep 26, 2013 at 3:48 PM, Domenic Denicola
Agreed. Not having attended the meeting, it seems like everyone's
suddenly gone crazy. ^_^
~TJ
Domenic Denicola <mailto:[email protected]>
September 26, 2013 3:48 PM
If it's going to be strings, it should be dunder, for consistency with
the already-existing cohort of proto/[define|lookup][G|S]etter. Having
two magic namespacing conventions in the language is insanity.
I don't understand why this is happening. There was fairly strong
consensus on symbols at the last meeting, and nothing new has been
brought to the table. Why are people's opinions suddenly changing?
Vague fearmongering about "complexity"? Symbols are a good solution to
a real problem, much better than strings.
Brendan Eich <mailto:[email protected]>
September 26, 2013 1:59 PM
@ is the new dunder -- dunder at -- dat.
Among the no-symbol proposals, I like this best. (GUIDs, shudder.)
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Kevin Smith <mailto:[email protected]>
September 26, 2013 6:11 AM
After thinking this over, I still remain unconvinced that symbols are
the right solution to the problem. Besides the fact that they
introduce (ever more) complexity to the object model, they simply do
not work as a duck-typing strategy for the real, *multi-realm* world
of Javascript. Sure, we can make a special case of standard library
symbols such that they maintain identity across realms. But a
solution which only works for special cases isn't a very good
solution, is it?
Here is another proposal which avoids these pitfalls:
1) Identify all meta-layer hooks using a string that is not an
identifier. The actual string used doesn't matter in this proposal,
but for illustration purposes I'll use an "@"-prefix.
2) Define all meta-layer hooks as functions. Testing for the hook
will involve [[Get]] followed by [[IsCallable]].
For example, defining an iterable:
class C { "@iterator"(...args) { /* ... */ } }
Overriding the string tag:
class C { "@toStringTag"() { return "[object C]"; } }
- Since the property name is a non-identifer, it is unlikely to
collide with any object members.
- Since the value of the hook must be a function, it is unlikely to
collide with keys in an object-as-map (e.g. a JSON object).
- Since it is just a string, it requires no changes to property
semantics, and it trivially works across realms.
{ Kevin }
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Kevin Smith <mailto:[email protected]>
September 25, 2013 11:53 AM
I think that your example _might_ do it, although I'll have to think
more about it tonight.
If so, then the justification for symbols at this point is based on
the dual use of JS objects as programming abstractions and as a
key-value data structure. Oh, javascript... : )
{ Kevin }
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
