Problems with strict-mode caller poisoning

Andreas Rossberg rossberg at google.com
Tue Nov 20 04:01:29 PST 2012


On 16 November 2012 22:19, Jeff Walden <jwalden+es at mit.edu> wrote:
> On 11/16/2012 07:06 AM, Brendan Eich wrote:
>> So it seems to me premature to throw on [[GetOwnProperty]] of a strict function's 'caller'. It would be more precise, and avoid the problem you're hitting, to return a property descriptor with a censored .value, or a poisoned-pill throwing-accessor .value.

That may be plausible, but requires making the 'value' property an
accessor, and hence breaks with the idea that descriptors are just
"records". But maybe that is OK for this hack? We should at least be
careful to define it such that the meaning and behaviour of the
descriptor does _not_ vary in time, which would be weird at best.
I.e., its return value and/or poisoning has to be determined once when
[[GetOwnProperty]] is executed.


> "premature to throw on [[GetOwnProperty]]("caller") on a function whose caller is strict", I assume you meant.  That seems right to me.  Since caller is a time-variant characteristic, it seems right for the property to be an accessor, probably existing solely on Function.prototype, and to defer all the strictness checks to when the function provided as |this| is actually invoked.

I'm not sure I follow, are you talking about the 'caller' property
itself now or the 'value' property of its descriptor?

The problem with 'caller' itself is that the spec does not (and
doesn't want to) spec it for non-strict functions, so it cannot
prescribe it to be an accessor. All would be fine, I suppose, if it
was.

If you are talking about the descriptor's 'value' property then I
strongly oppose making that vary in time. A time varying descriptor
would be weird at best. Fortunately, it's not necessary either.


> Such a property is no different from anything already in the language, so I can't see how it would at all interfere with Object.observe semantics or implementation.

See above, non-strict 'caller' is special in that the spec does not
try define it but yet guard against it with special, er, measures.

/Andreas


More information about the es-discuss mailing list