Yes, I thought of that -- currently o() throws, so in the best case,
there's no impediment to relaxing things to allow o() to call. In the
worst case, code that caught or counted on the exception somehow might
break.
Mainly the own-only restriction seems less-good compared to how, e.g.
proxy traps or accessors are found, via full prototype-based delegation.
Are some of these proposed and novel base-level traps better off
own-only, in spite of this general rule?
/be
David Bruant wrote:
Le 18/04/2012 17:14, Brendan Eich a écrit :
David Bruant wrote:
Change 11.2.3 "Function Calls" to use @call not [[Call]], passing
the /thisValue/ and /argList/ according to the
Function.prototype.call convention: (thisValue, ...argList).
@call as own property only or is it inherited as well?
I see no reason to require own.
After giving some more thoughts:
function f(){
return 12;
}
var o = Object.create(f);
o();
Currently this throws a TypeError (o isn't a function). If the @call
property was inherited, the inherited @call would be called (and no
error would be thrown).
I don't know to what extent it matters, but it's worth noting there
would be this difference.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
