We have exactly the same problem with inter-realm instanceof. The module system is the obvious solution for system-defined unique symbols. I've been assuming it could be hacked (one way or another) into giving us a registry where we could map string keys to symbols across realms. I get that this hack does nothing but bifurcates the namespace into *plain strings* and *symbol strings*. But for some cases this is a fine solution -- seems to work fine for ruby and smalltalk.
Maybe this would even merit syntax or some other language level treatment. If user-defined symbols come to pass (GUID-backed or otherwise) I'm sure *at least one* version of this kind of string-backed registry hack will pop up. Is it better to get ahead of it and limit it to only one by prescribing a solution (in spec. or elsewhere)? On Wed, Jul 31, 2013 at 11:03 AM, Mark Miller <[email protected]> wrote: > This point is important enough that I'm resending as the start of a new > thread. > > > On Wed, Jul 31, 2013 at 7:50 AM, Mark S. Miller <[email protected]>wrote: > >> >> In thinking about this, I become ever more puzzled about the versioning >> and inter-realm problems for user-defined unique symbols -- I think it may >> be a train wreck. Scenario: Library W version 1.1 defines and uses a unique >> symbol @foo which is loaded into realm A. Library W version 1.2 purposely >> intends to continue to define and use the "same" unique symbol @foo, so >> that W1.2 code can successfully handle instances of W1.1 code. Library W1.2 >> is loaded into realm B. The two realms come into contact, and objects from >> the two W's come into contact. *How did they both coordinate to define >> and use the same @foo symbol?* >> > > > > -- > Cheers, > --MarkM >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
