On 19 May 2011 17:09, Allen Wirfs-Brock <allen at wirfs-brock.com> 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

On 19 May 2011 17:09, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> 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.

> 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?