Tom Van Cutsem wrote:
2012/10/5 Domenic Denicola <[email protected]
<mailto:[email protected]>>
> 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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
