On Mar 20, 2008, at 11:31 PM, Jon Zeppieri wrote: > On 3/21/08, Jon Zeppieri <[EMAIL PROTECTED]> wrote: >> Are namespaces (and I'm not referring to the reflected objects >> here)... > > Except I am referring to those, aren't I?
What's a value? Types too have constant binding forms but runtime value status. Namespaces and types may be useful at runtime, e.g. for capability-like protection (you can read what you can name) and reflection. The choices so far for types have ruled out runtime type annotations, in order to support the optional strict mode's static checker and keep it efficient and fairly conventional. But we've talked about alternatives such as contracts (a la PLT Scheme). This goes way back. See, e.g. http://wiki.ecmascript.org/doku.php?id=proposals:contracts http://wiki.ecmascript.org/doku.php? id=proposals:discussion_about_contracts > >>> namespace ns1 >>> ns1 is Namespace > true > > So, at runtime, ns1 is the reflected object. That leaves that matter > of expression-qualified names... I wrote in reply to Mark that ES4's namespaces did not derive from E4X (ECMA-357). More the reverse, although of course XML namespaces were primary. SpiderMonkey supports E4X and runtime namespace qualifiers: js> ns = new Namespace("hi") hi js> o = {} [object Object] js> o.ns::p = 42 42 js> o.ns::p 42 js> id="p" // assume compiler can't propagate the constant "p" p js> o.ns::[id] 42 This is all in Firefox 1.5-3. I believe the intention among the core ES4 group over the last couple of years has been to support runtime qualifiers in ES4, as well. JS has computed property names since day 1: o[id] to access o.p. An optional strict mode can't reason about these, but they aren't the only loophole (eval, with, global non-fixtures). Why rule out runtime- computed qualified names (with either part computed at runtime)? Other core ES4 group members should chime in here. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
