2011/11/8 Allen Wirfs-Brock
> 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]] and [[Put]] p
Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eich 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 study.
I was curious
On 9 November 2011 00:16, Mark S. Miller wrote:
> On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg
> wrote:
>>
>> On 8 November 2011 20:46, Mark S. Miller wrote:
>> > Nevertheless, I see your point. Many defensive ES5 abstractions will be
>> > less
>> > defensive than this. If I understand you
2011/11/8 Allen Wirfs-Brock
> 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 [[HasProperty]] and then
>
On Tue, Nov 8, 2011 at 4:58 PM, Tom Van Cutsem 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 restriction,
for own (i in o) { //body
}
I'd rather see something like
for (i inside o) {
//body
}
And the reason for this is you could then use it in conditions as you use in:
if ( 'prop' in obj ) {
//body
}
if ( 'prop' inside obj ) {
//body
}
You would have
'prop' inside obj <=> Object.protot
On Wed, Nov 9, 2011 at 3:41 AM, David Bruant wrote:
> Le 09/11/2011 02:26, Andrew Paprocki a écrit :
>>
>> On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eich wrote:
>>>
>>> Ignoring performance, a lot of stylish JS hackers use
>>> Object.keys(o).forEach. How many run into the wrong |this|
>>> (argument
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" wrote:
> On Wed, Nov 9, 2011 at 3:41 AM, David Bruant wrote:
> > Le 09/11/2011 02:26, Andrew Paprocki a écrit :
> >>
> >> On Tue, Nov 8, 2011 at 6:36 PM, Br
On Wed, Nov 9, 2011 at 7:22 AM, Peter van der Zee 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
> 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:
>
> Object.keys(foo).forEach(function(key) {
> // this is
On 9 November 2011 16:10, John J Barton 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:
>
> Object.keys(foo).forEach(function(k
On Nov 9, 2011, at 3:53 AM, Tom Van Cutsem wrote:
> 2011/11/8 Allen Wirfs-Brock
> 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
On Nov 9, 2011, at 3:17 AM, Tom Van Cutsem wrote:
> 2011/11/8 Allen Wirfs-Brock
> 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 p
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) way to break out of a forEach 'loop' ?
--
Both the committee and JS coders could profit from examples.
The committee wants to ensure that their design decisions lead
to improvements in language usage, JS coders want to know
what those semi-formal proposals mean for their day-to-day
use of the language. Both parties want to be sure that t
On Wed, Nov 9, 2011 at 3: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
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 n
On Wed, Nov 9, 2011 at 4:05 PM, 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
On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
> On Wed, Nov 9, 2011 at 4:05 PM, 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) {
On Wed, Nov 9, 2011 at 4:20 PM, Brendan Eich wrote:
> On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
>
> On Wed, Nov 9, 2011 at 4:05 PM, 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,
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 block-lambdas they could have their cake and break
from it too (an
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.
>> W
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
>> 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-fre
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
> block-la
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.
I
>> 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 i
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 whe
On Nov 9, 2011, at 4:00 PM, Brendan Eich wrote:
> 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
On Wed, Nov 9, 2011 at 4:00 PM, Brendan Eich 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 elegant. But t
>>> 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 (J
On Nov 9, 2011, at 4:15 PM, Mark S. Miller wrote:
> On Wed, Nov 9, 2011 at 4:00 PM, Brendan Eich 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 thi
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 JavaSc
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 R
>
>
> 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)
36 matches
Mail list logo
