Comments on Sept Meeting Notes

Brendan Eich brendan at mozilla.com
Thu Sep 26 16:29:00 PDT 2013


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:jackalmage at gmail.com>
> 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:domenic at domenicdenicola.com>
> 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:brendan at mozilla.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> Kevin Smith <mailto:zenparsing at gmail.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> Kevin Smith <mailto:zenparsing at gmail.com>
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list