Not possible to use built-in namespaces to construct Name objects?

[lth]

Is it possible to create Name objects using built-in namespaces like public? At the very least it appears necessary to jump through some hoops (which I have not found). Consider:

>> namespace fnord
>> fnord
[user-defined namespace fnord]
>> (new intrinsic::Name(fnord, "x")).toString()
[user-defined namespace fnord]::x
>> (new intrinsic::Name(public, "x")).toString()
**ERROR** ParseError: qualified namespace without double colon
   (near <no filename>:1.1-1.1)

This is a problem if you want to create Name objects to pass to propertyIsEnumerable, for example.

[brendan]

Call or construct intrinsic::Name with only one argument, the identifier, and the qualifier defaults to null (now that #80 is fixed), which is the encoding of the "not a namespace" or (public "") namespace.

Did you want a way to denote a package's public namespace as an expression? Jeff, I dimly recall us talking about this a while ago.

/be

[lth]

Not really good enough, I'm looking for a solution allowing me to handle (at least) protected names as well.

The more general issue is that every user-defined namespace in the system is denotable, but built-ins are not. It's just a peculiar asymmetry in the language.

[brendan]

Jeff and I were just talking, and reasoned that:

1. Not all implementations reserved public/protected/private; none reserved internal. 2. So code could use public today in an expression, and want to find a binding, which could shadow a global binding if we were to add one for ES4 (treating the keyword as a pre-bound global). 3. So as with (type T) to make a value expression from a type expression T, it seems we need a special form to denote a built-in namespace in a value expression.

The obvious syntax is (namespace N) where N is public/protected/private/internal. Comments?

/be

[lth]

Another fun problem here came up on the mailing list (in a rudimentary form).

Suppose "private" is reified somehow, right now I'll just assume I can use it as an identifier like that, it's not important.

Then in a method

this.propertyIsEnumerable(new Name(private, "foo")), true)

will make private::foo enumerable.

Then an external entity performing enumeration:

for ( n in x ) ...

will presumably eventually receive a Name object in n that represents private::foo. Since that name object can be decomposed, the "private" namespace is now available outside the class.

This argues against making private/protected/public reified, and instead keeping it implicit like it is now.

[brendan]

We've talked about namespaces as capabilities, so that you could hand out a namespace through an API, and clients could use it to access otherwise-hidden names. But I agree it's bad if private can leak, ever. So wontfix?

/be

[lth]

Let's keep it warm a little longer. It's possible it's the enumeration behavior that's broken (eg, one should only enumerate properties in namespaces one has open)? I know that doesn't sound likely, but why not?

[lth]

As discussed here: http://wiki.ecmascript.org/doku.php?id=proposals:name_objects, the leaking can't be avoided for other reasons. So instead the bug is to fix enumeration/iteration, as defined there.

Thus I suggest that we adopt namespace N as syntax to get at Namespace objects for system-defined namespaces N in the set public,private,protected,internal.

[lth]

Also see #205.

[lth]

We should be able to write private in an expression context to grab the private namespace object.

[graydon]

All these are possible now, including 'return private;' and such. Though intrinsic::Name is now ES4::Name.