new function syntax and poison pill methods

David Bruant bruant.d at gmail.com
Fri Oct 26 15:13:59 PDT 2012


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121027/e7c7e84e/attachment-0001.html>


More information about the es-discuss mailing list