2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
I don't think that [[GetP]] and [[PutP]] need to be internal methods
In spec'ing this I think I would make them be abstract operations.
Internal methods are extensions points that can be over-ridden on a per
object basis. That is what [[Get]]
Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eichbren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to
On 9 November 2011 00:16, Mark S. Miller erig...@google.com wrote:
On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg rossb...@google.com
wrote:
On 8 November 2011 20:46, Mark S. Miller erig...@google.com wrote:
Nevertheless, I see your point. Many defensive ES5 abstractions will be
less
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote:
But I have a follow-up request. :) Regarding redundant trap calls with
proxies there is another, more pervasive problem with the current
spec: in lots of places it first calls
On Tue, Nov 8, 2011 at 4:58 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
Perhaps we should
be more conservative here, without necessarily backing away from the
whole
Proxy.attach idea?
Disallowing attaching to functions with your own call/construct traps
would be the minimal
On Wed, Nov 9, 2011 at 3:41 AM, David Bruant bruan...@gmail.com wrote:
Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eichbren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use
Object.keys(o).forEach. How many run into the
The forEach method might not do what you expect it to. This can not be
statically determined.
- peter
On 9 Nov 2011 16:10, John J Barton johnjbar...@johnjbarton.com wrote:
On Wed, Nov 9, 2011 at 3:41 AM, David Bruant bruan...@gmail.com wrote:
Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Wed, Nov 9, 2011 at 7:22 AM, Peter van der Zee e...@qfox.nl wrote:
The forEach method might not do what you expect it to. This can not be
statically determined.
And if forEach is not what you expect, that function may bind its argument:
foo(function() {
do something with |this|
2011/11/9 John J Barton johnjbar...@johnjbarton.com
I'm sure this has been discussed before, but isn't is possible and
desirable to make |this| illegal in using strict; when it can be
determined from the AST alone that |this| will bind to |window|? eg:
On 9 November 2011 16:10, John J Barton johnjbar...@johnjbarton.com wrote:
I'm sure this has been discussed before, but isn't is possible and
desirable to make |this| illegal in using strict; when it can be
determined from the AST alone that |this| will bind to |window|? eg:
On Nov 9, 2011, at 3:53 AM, Tom Van Cutsem wrote:
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote:
But I have a follow-up request. :) Regarding redundant trap calls with
proxies there is another, more pervasive problem with the current
On Nov 9, 2011, at 3:17 AM, Tom Van Cutsem wrote:
2011/11/8 Allen Wirfs-Brock al...@wirfs-brock.com
I don't think that [[GetP]] and [[PutP]] need to be internal methods
In spec'ing this I think I would make them be abstract operations. Internal
methods are extensions points that can be
On Wed, Nov 9, 2011 at 3:40 PM, Jorge jo...@jorgechamorro.com wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for a goto,
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for a goto, given that
there's no (easy)
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't
On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach(
On Wed, Nov 9, 2011 at 4:20 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as
On Nov 9, 2011, at 1:33 PM, Quildreen Motta wrote:
On 09/11/11 19:20, Brendan Eich wrote:
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
With
On Nov 9, 2011, at 1:33 PM, Dean Landolt wrote:
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
Aye, but I suspect that's because many people don't
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
With block-lambdas they could have their cake and break from it too (and the
call would be paren-free to
On Nov 9, 2011, at 2:43 PM, Axel Rauschmayer wrote:
Do block-lamdbas count as a fix for the dynamic this problem?
Definitely.
Or are there other plans to get it solved? I would still love to see that
happen, it’s a remarkably subtle source of errors. Could functions adopt the
Should ES.next provide sugar for the recommended pattern? To make it compose
with declarations and destructuring in the for head, it should use a
contextual keyword immediately after 'for':
for own (i in o) {
body
}
This is a small thing but it might pay off in the long run.
Or are there other plans to get it solved? I would still love to see that
happen, it’s a remarkably subtle source of errors. Could functions adopt the
block-lambda semantics of picking up the `this` of the surrounding scope
when not invoked as methods? It seems like that could work in
On Nov 9, 2011, at 3:48 PM, Axel Rauschmayer wrote:
Or are there other plans to get it solved? I would still love to see that
happen, it’s a remarkably subtle source of errors. Could functions adopt
the block-lambda semantics of picking up the `this` of the surrounding
scope when not
On Wed, Nov 9, 2011 at 4:00 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 3:48 PM, Axel Rauschmayer wrote:
We talked about lexical this for functions long ago (Jan. 2008? at Google
anyway) and IIRC Mark found a subtler flaw.
I think my original example was smaller and more
Got it. I’m assuming that’s a performance issue?
You could say that. If we inherit by default but it's a soft binding, then
the inner function has to carry that reference with it, but in a way that
can be overridden.
We talked about lexical this for functions long ago (Jan. 2008? at
On Nov 9, 2011, at 4:15 PM, Mark S. Miller wrote:
On Wed, Nov 9, 2011 at 4:00 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 3:48 PM, Axel Rauschmayer wrote:
We talked about lexical this for functions long ago (Jan. 2008? at Google
anyway) and IIRC Mark found a subtler
On Nov 9, 2011, at 10:55 , Claus Reinke wrote:
Both the committee and JS coders could profit from examples.
Amen to that. JavaScript seems worse than any other language when it comes to
finding correct information on the web. For example, I trust StackOverflow for
many topics, but for
Oops, I think I partially misread your email: You were talking about upcoming
changes and new patterns enabled by ES.next. But some of my observations should
still hold: You probably need a single person to write such material (or at
least to curate it).
Begin forwarded message:
From: Axel
Amen to that. JavaScript seems worse than any other language when it comes
to finding correct information on the web. For example, I trust
StackOverflow for many topics, but for JavaScript, it’s often shockingly
wrong. Half-truths are even worse than information that is completely wrong.
On 09/11/2011, at 22:05, Brendan Eich wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for
31 matches
Mail list logo
