Russell Leggett wrote:
import {apply,unapply} from "@extractor";
const Twice = {
[apply]:function(x){
return x * 2;
},
This would have made pre-Proxies Narcissus a piece of cake. Instead I
had to extend SpiderMonkey (__call__, __construct__, etc. --
unstratified meta-methods a la Python).
Anyway, there's no deep reason other than (typeof x == "function") <=>
(x is callable) for a native (not host) object x. I didn't have time to
put callability into the base language in the first ten days, and no one
was motivated to do so for ES1. After that it was off the agenda.
Optimizing implementations, secure program analyses, and other "readers"
might object to losing the (typeof x == "function") <=> (x is callable)
invariant, but it doesn't help in practice due to host objects. JS
engines already must optimize based on built-in and/or inferred type,
hidden class, etc., and many super-optimizefunction calls (inline,
specialize by argument types and values). Host objects require special
handling (de-optimization or separate-from-function optimization if
worthwhile).
With direct proxies we have an incremental solution for ES6. I don't see
a for-all-objects base-level approach that uses hidden names passing
into ES6 at this point. Doing it later is even less helpful. But worth
discussing -- the need to create a direct proxy or function in advance
of needing some (other) object to be callable does get in the way sometimes.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
