Le 26/10/2012 23:57, Mark S. Miller a écrit : > #3 as is does not require implementations to not provide magic > insecurable "caller" and "arguments" properties, just as ES5 by itself > does not require implementations to not provide such properties on > built-ins. Indeed, before many side conversations, there were > conforming implementations that had non-configurable (and hence > non-deletable) magic "caller" and "arguments" properties on built-ins. > SES could not these platforms at reasonable cost. Fortunately, we were > able to convince all such platforms to change even without the power > of a normative spec behind us. > > #3-prime would require that these not be provided, so that it would > correspond correctly to your description: 'there is no "caller" nor > "arguments" property at all'. Ok. I had misunderstood Allen's #3 as your #3-prime then. I would favor #3-prime, but can't help noticing that it's a really odd requirement. The spec would have "there is no caller or arguments at all", but that's only until an implementation adds another non-standard property name providing abusive authority that will have to be banned too.
I think the oddity I note is a consequence of the too loose paragraph in section 2: "A conforming implementation of ECMAScript is permitted to provide additional types, values, objects, properties, and functions beyond those described in this specification. In particular, a conforming implementation of ECMAScript is permitted to provide properties not described in this specification, and values for those properties, for objects that are described in this specification." Instead of having an "there is no 'caller' nor 'arguments' property at all" rule, maybe it would be a good idea to refine this paragraph to say what's permitted and what is not. For instance, mention that for function objects, there cannot be a property (regardless of its name!) providing access to the caller function during runtime, etc. With this kind of refinement (potentially reminded as a note in the relevant subsections), it may be easier to share and document the intent of what is acceptable to provide as authority and more importantly what is not. David
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
