On Wed, Sep 11, 2013 at 8:30 PM, Waldemar Horwat walde...@google.com wrote:
On 09/11/2013 03:38 PM, Jason Orendorff wrote:
But as Allen said, [[Invoke]] is not a performance hack. It's a
correctness hack.
It permits proxies to customize their behavior around `this`, and even
naive .invoke
On Wed, Sep 11, 2013 at 7:51 PM, Brendan Eich bren...@mozilla.com wrote:
You could be right, but this is a deep topic, not sorted out by programming
language developers, in my view. It came up recently here:
http://www.haskell.org/pipermail/haskell-cafe/2013-September/108654.html
That thread
[+markm, allenwb]
2013/9/11 David Bruant bruan...@gmail.com
Le 11/09/2013 16:22, Tom Van Cutsem a écrit :
[[GetInheritance]] always checks whether the proxy and target's
prototype are the same, but as you pointed out, if the target is
extensible, you can set its prototype to some other
I'm willing to call them [[GetPrototypeOf]] and [[SetPrototypeOf]] to
match the trap names. I prefer avoiding a direct connotation with the
[[Prototype]] internal data property as an exotic object is not required to
have one.
I'm all for matching the internal method names with the trap and
2013/9/11 Brendan Eich bren...@mozilla.com
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?
Trap method calls
2013/9/11 Allen Wirfs-Brock al...@wirfs-brock.com
I'm not sold. Two internal methods means there must be two proxy traps
that must always be implemented as a pair. It would simply be wrong for a
handler to implement the invoke trap and not also implement the
invokeConditional trap. And
2013/9/12 Till Schneidereit t...@tillschneidereit.net
I agree, anything else would be surprising. But can't we make the .invoke
trap work for both [[Invoke]] and [[InvokeConditional]]? It would just
always be called, and the places where [[InvokeConditional]] is used in the
spec would treat
2013/9/12 Allen Wirfs-Brock al...@wirfs-brock.com
what Tom was referring to above: statically separate the cases into two
separate internal methods.
I presume, in context, he means [[Invoke]] and [[ConditionalInvoke]] but
it could also mean [[Invoke]] and [[InvokeFunction]]
Yes (I meant
On Thu, Sep 12, 2013 at 2:35 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/9/12 Till Schneidereit t...@tillschneidereit.net
I agree, anything else would be surprising. But can't we make the .invoke
trap work for both [[Invoke]] and [[InvokeConditional]]? It would just
always be called,
On Thu, Sep 12, 2013 at 4:14 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[+markm, allenwb]
2013/9/11 David Bruant bruan...@gmail.com
Le 11/09/2013 16:22, Tom Van Cutsem a écrit :
[[GetInheritance]] always checks whether the proxy and target's
prototype are the same, but as you pointed
Le 12/09/2013 15:35, Mark S. Miller a écrit :
On Thu, Sep 12, 2013 at 4:14 AM, Tom Van Cutsem tomvc...@gmail.com
mailto:tomvc...@gmail.com wrote:
[+markm, allenwb]
But more generally, you're right that it's odd [[GetInheritance]]
is doing an invariant check on an otherwise
On 12 September 2013 01:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
For now, I'm going to try giving each semantic routine in a subsection, a
section number. Note this may include multiple algorithms corresponding to
various productions. I'll also add a see also under each such
On Sep 12, 2013, at 6:35 AM, Mark S. Miller wrote:
On Thu, Sep 12, 2013 at 4:14 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[+markm, allenwb]
2013/9/11 David Bruant bruan...@gmail.com
Le 11/09/2013 16:22, Tom Van Cutsem a écrit :
[[GetInheritance]] always checks whether the proxy and
Membranes need shadow targets, because of non-extensibility of objects and
non-configurability of properties. This special case of
no-invariants-anywhere is not JavaScript. Trying to do membranes without
shadow targets is a useless exercise.
On Thu, Sep 12, 2013 at 8:03 AM, David Bruant
On 9/12/13 11:03 AM, David Bruant wrote:
If the code that runs
against your membrane is not expected to be allowed to change
extensiveness
It's absolutely expected to be allowed to do that. You should be able
to freeze objects coming from another global.
-Boris
Anne van Kesteren mailto:ann...@annevk.nl
September 12, 2013 11:39 AM
I would be okay with not doing these additions until we are more
confident about the correct solution. The polyfills for these are
relatively straightforward and documented on MDN.
Or is your argument that this code point
On Sep 12, 2013, at 7:51 AM, Andreas Rossberg rossb...@google.com wrote:
On 12 September 2013 01:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
For now, I'm going to try giving each semantic routine in a subsection, a
section number. Note this may include multiple algorithms
On Thu, Sep 12, 2013 at 6:42 PM, Brendan Eich bren...@mozilla.com wrote:
Iterators forward and (if needed backward) over Unicode characters (scalar
values; I'm allowed to call those characters, no?) would be good. Github
beats TC39 as usual, prollyfill FTW.
No, there a non-characters that are
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
function f(x=h(), y) {
function h() { ... }
}
is evaluated in the scope of f, as I expected, so {x, h, y} are all in
scope
On Sep 12, 2013, at 12:45 PM, Oliver Hunt wrote:
On Sep 12, 2013, at 12:40 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
I thought we agreed with Andreas Rossberg's proposal to isolate default
expressions from hoisted body declarations, as if (kind of) desugaring
var x = outer;
function f(a = x, b = y) {
var x = inner;
function y() {}
body code here;
}
to
var x = outer;
function f(a) {
if (a === undefined) a =
On Sep 12, 2013, at 12:40 PM, Jason Orendorff wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
function f(x=h(), y) {
function h() { ... }
}
is evaluated in
On Sep 12, 2013, at 12:40 PM, Jason Orendorff jason.orendo...@gmail.com wrote:
Just as a worked example, answering Oliver's question about default
expressions took me the better part of an hour.
The default-expression h() in code like
function f(x=h(), y) {
function h() { ...
On 9/12/2013 12:45 PM, Oliver Hunt wrote:
From talking to SpiderMonkey folk it sounds like SM nukes the |arguments|
identifier entirely if you use any of the new parameter logic (deconstruction,
defaults, or rest params). I would be happy with that.
This doesn't seem to be accurate, or I'm
24 matches
Mail list logo
