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. --lars _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
