Symbols, Protocols, Frames, and Versioning

Brendan Eich brendan at mozilla.com
Fri Oct 5 11:13:15 PDT 2012


Tom Van Cutsem wrote:
> 2012/10/5 Domenic Denicola <domenic at domenicdenicola.com 
> <mailto:domenic at domenicdenicola.com>>
>
>     > Indeed, which is why I'm not sure I understand what this idea is
>     trying to achieve. Is it more than just an ad hoc way to introduce
>     a second namespace?
>
>     Yes, is this noticeably better than just saying "use
>     '__space_of_strings_<string>'"? What does this new API accomplish
>     that can't already be done with a conventional prefix in the
>     normal space of strings?
>
>
> I also find Symbol.for questionable. If everyone starts to define 
> their symbols using Symbol.for, we have achieved nothing in the way of 
> uniqueness/unforgeability.

Yes, all we'll have done is dodged a name collision with a 
string-equated property name, at the price of new API and boilerplate 
using it, plus risk of collision on the argument to Symbol.for!

For the specific case of the iteration protocol, I'd rather use 
'iterator' (no dunder affixes) at that point.

> If symbols break across frames, I think the fault lies not with the 
> symbols. I think the fault lies with the fact that the object on which 
> the symbol was defined didn't "properly" cross the frame boundaries. 
> Perhaps we need better abstractions to interpose between frame boundaries?

Good point. See

https://developer.mozilla.org/en-US/docs/XPConnect_security_membranes#XPCCrossOriginWrapper

where we nevertheless took advantage of same-process reachability among 
same-origin frames/windows.

This diagram is now out of date. We always membrane-wrap when crossing 
frame or window boundaries in Gecko. The membrane for same-origin window 
boundaries is quite thin, but it could handle symbol unification as you 
suggest.

/be


More information about the es-discuss mailing list