ES4 note: Reserved namespaces
I agree with everything except:
- reserved namespaces may not be aliased (ie they are illegal on the right hand side of "=" in "namespace ns1 = ns2")
If we want to make reserved namespaces into keywords, that might be ok. However, at the current time they're not keywords, and one could write:
const foo = intrinsic;
and:
namespace instrinsic = my_namespace;
Being able to write those but not:
namespace foo = intrinsic;
is just splitting hairs without achieving anything important. You still shouldn't be able to define properties in the reserved namespaces except as outlined in the proposal.
One can also write:
var intrinsic = 3;
which (I hope) would shadow the intrinsic namespace within its hoisted scope.
Waldemar-----Original Message----- From: Waldemar Horwat [mailto:waldemar at google.com] Sent: 28. april 2008 18:39 To: Lars Hansen Cc: es4-discuss Subject: Re: ES4 note: Reserved namespaces
I agree with everything except:
- reserved namespaces may not be aliased (ie they are illegal on the right hand side of "=" in "namespace ns1 = ns2")
If we want to make reserved namespaces into keywords,
We do not...
that might be ok. However, at the current time they're not keywords, and one could write:
const foo = intrinsic;
But "foo" can't be used as a namespace qualifier in any context, so that's OK.
and:
namespace instrinsic = my_namespace;
That one either shadows an existing namespace or causes an ambiguity, so I don't think that's a problem either.
Being able to write those but not:
namespace foo = intrinsic;
is just splitting hairs without achieving anything important.
I disagree. The rules guarantee that it is possible for the implementation to determine statically whether a particular fixture definition introduces a binding in one of the reserved namespaces. (That actually depends on namespace annotations always being statically resolvable. Some of the details of how that's handled are still open but that's the goal.)
You still shouldn't be able to define properties in the reserved namespaces except as outlined in the proposal.
One can also write:
var intrinsic = 3;
which (I hope) would shadow the intrinsic namespace within its hoisted scope.
It should, and it's considered desirable that this would work, which is why the reserved namespaces are not reserved words.
Lars Hansen wrote:
-----Original Message----- From: Waldemar Horwat [mailto:waldemar at google.com] Sent: 28. april 2008 18:39 To: Lars Hansen Cc: es4-discuss Subject: Re: ES4 note: Reserved namespaces
I agree with everything except:
- reserved namespaces may not be aliased (ie they are illegal on the right hand side of "=" in "namespace ns1 = ns2")
If we want to make reserved namespaces into keywords,
We do not...
that might be ok. However, at the current time they're not keywords, and one could write:
const foo = intrinsic;
But "foo" can't be used as a namespace qualifier in any context, so that's OK.
and:
namespace instrinsic = my_namespace;
That one either shadows an existing namespace or causes an ambiguity, so I don't think that's a problem either.
Being able to write those but not:
namespace foo = intrinsic;
is just splitting hairs without achieving anything important.
I disagree. The rules guarantee that it is possible for the implementation to determine statically whether a particular fixture definition introduces a binding in one of the reserved namespaces. (That actually depends on namespace annotations always being statically resolvable. Some of the details of how that's handled are still open but that's the goal.)
That's missing the point. As far as I've seen in this discussion so far, prohibiting
namespace foo = intrinsic;
does not achieve anything important and it does introduce a weird asymmetry (and yet another strange rule for programmers to memorize) into the language. It does not achieve the guarantee that it's statically possible to determine whether a particular fixture definition introduces a binding in one of the reserved namespaces. That guarantee is satisfied by resolving namespaces at compile time, with or without this prohibition.
Waldemar
We've had this notion for a while that some namespaces are "reserved", that is, you can't use them for your own properties except in well-defined ways. The notion of reserved namespaces seems to be important for future-proofing the language: we may wish to introduce new names in those namespaces and it's important that user definitions not get in the way.
Without teeth there is no way that we can make the notion of reserved namespaces stick, so here's a brief writeup about what we think those teeth might look like. Please look for cavities.
There are three important reserved namespaces, they have different restrictions:
"reflect" is used to tag reflection methods on type objects. User code may not define properties (including methods) in this namespace at all.
"intrinsic" is used to tag instance methods. User code may override existing methods in this namespace in subclasses but may not otherwise define properties in this namespace.
"meta" is used to tag static and instance catchall (get, set, has, delete, and invoke) methods. User code may introduce or override these five methods but may not otherwise define properties in this namespace.
The rules are:
reserved namespaces may not be aliased (ie they are illegal on the right hand side of "=" in "namespace ns1 = ns2")
any attempt to introduce fixture properties on objects in a way that contradicts the restrictions described above shall cause a syntax error to be thrown.
(The namespaces are not reserved words, but we believe it is always possible to detect statically whether a namespace reference that might be used to introduce a fixture is to one of the reserved namespaces; the first rule above is not even necessary, it just makes code more readable by requiring the reserved namespaces always to be spelled the same way.)
The most important consequence of the rule is that when a future revision of the language introduces a new name in a reserved namespace, there is a guarantee (modulo vendor extensions, but presumably they will be taken into account if the language is revised) that there will not be a fixture in any user program that uses that name, and any existing dynamic properties on the object's prototype will be shadowed by the new fixture.
Another consequence of the rules is that user code may introduce dynamic properties in the reserved namespaces. This is considered a feature; the use case is that user code may be able to compensate for missing intrinsic, reflect, and possibly meta methods in one implementation by introducing the corresponding prototype methods.