Brandon Benvie <mailto:[email protected]>
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something
as simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]]
as currently specced gets us somewhere at least.
Somewhere half-right and half-wrong, depending on target object details
over which a single trap cannot hope to abstract, is still half-wrong.
Membranes based on built-in libraries should be easy enough to use.
That does mean we have to get the built-in libraries right. Something
best done on github (see promises), but then potentially absorbed by the
spec in short order (whichever spec is in the right rapid-er release
stage to absorb the library).
Tom, are you happy with the state of the proxy-supporting libraries for ES6?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Brendan Eich <mailto:[email protected]>
September 24, 2013 11:38 AM
Based on all the great input (thanks to André for his summary, and
Mark for pointing out "works always" beats "half-works/half-broken"),
and talking to Allen 1:1, I'm back to status quo ante: we are better
off being conservative designers by deferring invoke.
If we need to trial it as a strawman extension in SpiderMonkey, we can
do that, and we'll report back.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
September 24, 2013 10:54 AM
The main issue is the use case exemplified by:
let temp = thing.f;
//do other stuff using temp
temp.call(thing,...args)
I have previously suggested that the fix for this if [[Invoke]] is
used to implement the call operator is:
let temp = thing.f;
//do other stuff temp
thing.f(...args)
In addition, I proposed that where this use case appears in the ES
spec ([[Get]]+stuff+[[Call]]) it should be replaced with
[[Get]]+stuff+[[Invoke]].
The object to this is that it observably does two property lookups of
"f" while [[Get]]+[[Call]] only does one. Personally, I think this is
probably a insignificant change from the ES5 semantics, but trying to
avoid it is one of the forces pushing towards using [[InvokeFunction]].
A separate concern is that even though in ES6 thing.f(...ags) is
probably better than temp.call(thing,...args) it isn't the pattern
existing JS programmers use.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Mark S. Miller <mailto:[email protected]>
September 24, 2013 10:06 AM
I do not know and I do not know what to search on to find out.
However, I would guess it is used enough to be a real concern. We
documented it at
<http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming>
for reasons that are not Caja specific. That page followed from Axel's
<http://www.2ality.com/2011/11/uncurrying-this.html> which is also not
Caja specific. Both have been public advice posted in places prominent
to the JS community for a long time. There was also an earlier
discussion on es-discuss about exactly this integrity issue, that was
again not Caja specific.
But anyway, another point of my email is that I don't understand what
problem you're trying to solve. The reason for using this pattern,
rather than the much simpler thing.f(...args) is to take control away
from thing. If you give control back to thing anyway, what's the
point? If you want thing to have control, why not write thing.f(...args) ?
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
September 24, 2013 9:47 AM
Mark,
In the wild, how often do you think F.p.call is used with these sorts
of integrity guarantees in mind? Does anybody other than Caja do it?
If we are really only talking about Caja, it presumably could adapt
to using Reflect.apply.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
