Tom Van Cutsem <mailto:[email protected]>
September 11, 2013 7:08 AM
1) The [[Invoke]] operation is meant to primarily trap method calls
generated by user-code of the form |obj.m(...args)|. This is by far
the most common case, and I believe we should not extend [[Invoke]]
with additional arguments that are irrelevant to this primary use
case. Rather than having a boolean argument, better to statically
separate the cases into two separate internal methods.
+a bazillion. Srsly!
2) There are a number of places in the spec where [[Invoke]] should be
called conditionally, if we know for sure the property is callable.
Currently the pattern for this is [[Get]]+[[Call]]. We cannot refactor
to [[Has]] + [[Invoke]] in general, because [[Has]] will return true
also for non-callable values.
This is the toString/valueOf legacy.
If we believe these are call-sites where it is worth avoiding the
allocation of a function, then having an additional internal method
like [[GetMethod]] or [[InvokeConditional]] makes sense, but I doubt
it's worth the added complexity.
We have zero evidence based on legacy (i.e. what's deployed).
3) For proxy trap invocations I maintain we are still better off with
[[Get]] + [[Call]] to keep double-lifting as simple as possible.
Sorry if I missed it: what complicates things if we use [[Invoke]] to
support double-lifting?
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
