caller poison pills, revisited (Was: A few arrow function specification issues)

Allen Wirfs-Brock allen at
Mon Apr 23 11:13:44 PDT 2012

On Apr 23, 2012, at 10:18 AM, Brandon Benvie wrote:

> > 6) Do arrow functions need to have per instance "caller" and "arguments" poison pill properties?
> >
> > I propose no, because they are a new feature. But we can include a NOTE warning against providing their non-standard legacy implementation.
> For simplicity and uniformity, I'd keep the same semantics as for
> ordinary functions. Don't special-case if there is no strong reason to
> do so. 
> Can arrow functions just not have arguments, caller, and name at all? I have to say, it's really annoying having to special case these properties when trying to create function proxies that are mostly virtual, as they are non-configurable, non-writable, and own properties.

It at least partially depends upon the properties of Function.prototype because if a arrow function does not implement these properties as own properties it will inherit their definitions (or lack, there of) from Function.prototype.

This raises the issue that ES5.1 overlooked poisoning caller/arguments for Function.prototype.  Only function object created using the algorithm in 13.2 have the the poison pill properties and Function.prototype is not specified using 13.2.

I'm becoming increasing convinced that the poison pill approach to securing the caller chain is a poor approach.  We keep finding leaks in and it does nothing to prevent implementation from inventing new ways to expose the stating they are trying to hide. I now think we would be better off with a general,non-algorithmic restriction on conforming implementation that forbid them from exposing elements of the caller chain in the situations that the poison pills were intended to address.  

I'd like MarkM or other SES advocates to propose language that expression the restriction they need. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list