On 19 May 2011 17:09, Allen Wirfs-Brock <[email protected]> wrote: >> Hm, making name creation a method of String seems equally odd -- >> unless you also plan to have typeof String.createPrivateName() == >> "string". > > That is indeed the plan in the particular version of the proposal that > started this thread.
You mean the unique_string_values proposal that Luke mentioned? Hm... Doesn't that have similar potential for breaking code? Existing code could make lots of assumptions about what it can do with a value if its type equals "string". Unless I misunderstand something, "secret" strings would break some of those (valid) assumptions. >> Of course, I see the concern with the global object (although 'Name' >> was only a strawman suggestion). I assume that we need a future-proof >> solution for adding new built-in objects anyway, most likely based on >> modules. And that accessing built-in objects through the global object >> will be deprecated in Harmony code. So, since private names will be >> Harmony-specific, their constructor doesn't have to be visible through >> the "old" ES5 global object. > > This thread initially was specifically about how to make private name > creation available in code that does not opt-in into new Harmony syntax. My apologies, you are right. But how would such a proposal affect the Harmony side of things? Is the intention to have it replace a proper type of private names in Harmony, or merely complement it? Thanks, /Andreas _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
