Function proxy length (Was: length property value for functions with parameter enhancements)

David Bruant david.bruant at labri.fr
Tue Aug 30 11:23:23 PDT 2011


Le 30/08/2011 20:00, Andreas Rossberg a écrit :
> On 30 August 2011 18:41, David Bruant <david.bruant at labri.fr
> <mailto:david.bruant at labri.fr>> wrote:
>
>     This would facilitate the author work when it comes to creating
>     functions that look like functions without having to always
>     include some initialization code for .length, .prototype and such.
>     It will still be possible to opt-out of .length or .prototype if
>     the author doesn't
>
>
> I don't think it's worth introducing special cases in the semantics,
> especially not for something like length. Proxy authors already have
> to do a lot of similar work, e.g. to make all the standard
> Object.prototype and Function.prototype methods available on proxies.
Actually, the situation is a bit different.
If strawman:handler_access_to_proxy [1] is accepted (which seems to
slowly come to an agreement based on the "July TC39 meeting notes, day
1" thread), then all inheritance-related traps become derived, so in
order to have proper inheritance, authors just have to not define these
traps (and set the correct prototype object of course).
Or am I missing a case?

f.length and f.prototype are own properties. As such, there is no such
convenience.

> I think this problem is something that should be solved by the
> library, not the proxy API itself. Maybe we can find some nice
> building blocks for handlers that make available the basic
> functionality in a convenient and extensible way?
For f.prototype, it should be ok, but f.length will require to provide
callTrap to the building block (or callTrap.length). Why not have this
by default embedded in the API where callTrap has to be passed anyway?
Also, I think that by default providing a .length, .prototype and having
a relevant behavior when it come to strict mode .caller and .arguments
would better reflect the default intent of the programmer.

David

[1] http://wiki.ecmascript.org/doku.php?id=strawman:handler_access_to_proxy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110830/da163ff6/attachment-0001.html>


More information about the es-discuss mailing list