Symbols, Protocols, Frames, and Versioning

Tom Van Cutsem tomvc.be at gmail.com
Fri Oct 5 06:26:56 PDT 2012


2012/10/5 Domenic Denicola <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.

It seems to me the only reasonable way to deal with globally unique symbols
is to always make sure that any object containing symbols that crosses
frames is serialized and unserialized in such a way that a "global" symbol
from the originating frame is deserialized into the corresponding "global"
symbol from the recipient frame. That's how one needs to deal with these
issues in distributed computing between isolated processes as well.

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?

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121005/a4286d46/attachment.html>


More information about the es-discuss mailing list