Symbols, Protocols, Frames, and Versioning
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
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
where we nevertheless took advantage of same-process reachability among
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
More information about the es-discuss