True. OK, given that it’ll be mostly library implementers (as in “smart
people”) who will use this mechanism, nicer surface syntax might not be
necessary (and could even be provided by yet another library).
On Mar 28, 2012, at 6:06 , Allen Wirfs-Brock wrote:
On Mar 27, 2012, at 12:18 PM,
The ambiguity between a block body and an object literal expression body,
which we would prefer to resolve in favor of object literal. The solutions
considered before this edit were:
* http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
* Two-token lookahead restriction per
In another thread Allen says:
we infer from array behavior that for-in was intended to iterate over
the data elements of an object and not the behavioral elements (eg methods).
Similar comments have been implied around the discussion of enumerable
properties. I personally have never seen any
On Mar 28, 2012, at 17:06 , John J Barton wrote:
In another thread Allen says:
we infer from array behavior that for-in was intended to iterate over the
data elements of an object and not the behavioral elements (eg methods).
Similar comments have been implied around the discussion of
On Tue, Mar 27, 2012 at 9:39 PM, Luke Hoban lu...@microsoft.com wrote:
Brendan Eich wrote:
Kevin's analysis contradicts your assertion. Expression-bodied
functions with bound |this| (or var self=this outside) predominate in
the code he surveyed.
See thread headed by this message:
On Mar 28, 2012, at 8:06 AM, John J Barton wrote:
In another thread Allen says:
we infer from array behavior that for-in was intended to iterate over the
data elements of an object and not the behavioral elements (eg methods).
Similar comments have been implied around the discussion
On the other hand, failing to bind 'this' is something that I believe every
single JS developer hits routinely. It has cost them time to recognize and
recover. The net advantage of a better bind mechanism still depends upon many
issues, but this problem has much bigger impact that eight vs
On Wed, Mar 28, 2012 at 8:24 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 28, 2012, at 8:06 AM, John J Barton wrote:
In another thread Allen says:
we infer from array behavior that for-in was intended to iterate over
the data elements of an object and not the behavioral
I'd love to see this implemented natively ...
(function (Object) {
var
forEach = forEach,
ObjectPrototype = Object.prototype
getOwnPropertyNames = Object.getOwnPropertyNames,
getOwnPropertyDescriptor = Object.getOwnPropertyDescriptor
;
forEach in ObjectPrototype ||
actually, to be consistent with Array.prototype.forEach, descriptor should
be the first argument ... apologies
On Wed, Mar 28, 2012 at 5:39 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I'd love to see this implemented natively ...
(function (Object) {
var
forEach =
For ES5, we made the decision to keep new meta-programming APIs off of
Object.prototype. I think it was a wise decision. Consistent with it, if we
added something like this it would be on Object, not Object.prototype or more
likely in ES6 in a built-in module.
However, you have nicely
On Mar 28, 2012, at 8:26 AM, Axel Rauschmayer wrote:
On the other hand, failing to bind 'this' is something that I believe every
single JS developer hits routinely. It has cost them time to recognize and
recover. The net advantage of a better bind mechanism still depends upon
many issues,
Well, that forEach is shadowed by Array.prototype.forEach while forIn will
scale with arrays too ... in ES5 many global prototype have been
implemented over existing libraries indeed but what we all deal with on
daily basis are mostly Objects and few methods there could be handy.
Regardless these
we need either fat arrow or block lambda based TCP preserving functions.
We don't need thin arrow and we really don't need the confusion it would
create.
What about situations where the user wants bound |this|, but no other TCP
stuff? Callbacks and a large portion of event handlers fall
I've been championing this syntax since Dave proposed it as the tri-lambda
syntax. Through this, I've exposed many JavaScript programmers of varying
experience (from fellow bocoupers to our JavaScript training sessions -
overhwhelmingly actionscript or ruby devs) to the three major pieces:
*Just
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case is
passing a method as an argument but needing to retain the correct this.
Obviously, that is what bind was meant for, but that is inconvenient when
passing methods for
On Wed, Mar 28, 2012 at 1:37 PM, David Herman dher...@mozilla.com wrote:
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case is
passing a method as an argument but needing to retain the correct this.
Obviously, that is
On Wed, Mar 28, 2012 at 2:02 PM, Russell Leggett
russell.legg...@gmail.comwrote:
Ah, there you go. I figured I wasn't the first to think of it. I think it
might be worth talking about this in relation to the shorthand function
syntax, because it could pull the lexical this issue out of that
Rick provides anecdotal evidence for the idea that a lexically bound |this|
form would provide great benefit.
But I believe that using do expressions for lexically binding |this| is
going to cause the following problems for beginning and intermediate
programmers:
- Unintentionally leaking the
*Just a short hand:*
let thin = ( a ) - { return x; };
The general response to this is that it makes complete sense: just
syntax and just shorthand are common i get it nowphrases. Also,
this is highly desirable ie. they want it now.
Despite users wanting this, the numbers seem to
I'm not sure how to quantify this, but I believe that if such a bind
operator were available, it would be overwhelmingly be used to simulate
lexical |this|.
If syntax is about optimizing the common case, then shouldn't we just
provide a function form which lexically binds |this|?
kevin
On Wed, Mar 28, 2012 at 2:38 PM, John Tamplin j...@google.com wrote:
On Wed, Mar 28, 2012 at 2:02 PM, Russell Leggett
russell.legg...@gmail.com wrote:
Ah, there you go. I figured I wasn't the first to think of it. I think it
might be worth talking about this in relation to the shorthand
On Wed, Mar 28, 2012 at 3:17 PM, Kevin Smith khs4...@gmail.com wrote:
I'm not sure how to quantify this, but I believe that if such a bind
operator were available, it would be overwhelmingly be used to simulate
lexical |this|.
If syntax is about optimizing the common case, then shouldn't we
- Incorrectly using return for those that don't fully understand TCP.
As an illustration, consider this case:
element.onclick = (evt) = do {
if (this.alreadyWaitingForAjaxResponse)
return;
this.startAnAjaxRequest();
};
Presumably the early return will
Thats not the only common case. It might be *the most* common, but I see a
lot method pointers that need binding too.
Can you post an example?
kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Mar 28, 2012 at 3:26 PM, Kevin Smith khs4...@gmail.com wrote:
- Incorrectly using return for those that don't fully understand TCP.
As an illustration, consider this case:
element.onclick = (evt) = do {
if (this.alreadyWaitingForAjaxResponse)
return;
Russell, I looked at the other thread more carefully and now understand
what you're saying. Can't we use a bound |this| function for all these
cases?
needsCallback(x = foo.bar(x));
needsCallback(x = this.bar(x));
// Suppose for a moment that - also binds |this|
needsCallback((x,
On Wed, Mar 28, 2012 at 9:57 PM, Kevin Smith khs4...@gmail.com wrote:
It seems that with bound |this| functions, the need to explicitly bind
|this| tends to fall away.
This is true for function literals that needs to be bound to the `this`
context in the scope where they're created, but not
BTW, there's also some discussion on a bind operator at a ticket I opened
on CoffeeScript's tracker,
https://github.com/jashkenas/coffee-script/issues/2136 (slightly based on
the syntax proposed on Sugar for *.prototype and for calling methods as
functions
Kevin Smith wrote:
I hate the CoffeeScript deviation, though. It's just confusing for
anyone who ever learned that fat-arrow binds |this| and thin-arrow
doesn't.
True. On the other hand, all arrows bind |this| is also quite
simple and easy to remember.
Yes, and I kept the part
On Wed, Mar 28, 2012 at 3:57 PM, Kevin Smith khs4...@gmail.com wrote:
Russell, I looked at the other thread more carefully and now understand
what you're saying. Can't we use a bound |this| function for all these
cases?
needsCallback(x = foo.bar(x));
needsCallback(x = this.bar(x));
Luke Hoban wrote:
Yeah - I followed the earlier discussion on the data Kevin gathered, which is great input. From the spreadsheet linked in Kevin's mail above, it looks like 81% of function expressions had statement bodies, and50% did not reference this. While these were cast as BTF candidates,
Allen Wirfs-Brock wrote:
We don't need thin arrow and we really don't need the confusion it
would create.
The case for thin-arrow is body block. Instead rejecting - and
approving do-expressions results in something a bit overlong (=do) that
has TCP. And I think it's plausible that this will
I find this proposal backwards. It requires an expeession as the right
hand side. Alex proposed something similar a long time ago. He
suggested using '!' instead of '.'. This is important because the
common use case we want to solve is to make 'obj.foo.bind(foo)' be
written as 'obj!foo'. With your
On Wed, Mar 28, 2012 at 5:19 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
I find this proposal backwards. It requires an expeession as the right
hand side. Alex proposed something similar a long time ago. He
suggested using '!' instead of '.'. This is important because the
common use
Here are my rough notes from today's meeting.
Waldemar
-
IPR discussion
Intel changed their ECMAScript patent declaration to RANDZ.
Now they wonder why no one else made a RANDZ declaration.
Istvan described the history.
Mozilla is also unhappy with the current state of affairs. Even
If the consensus is that two arrows are too confusing, and we must choose
to prefer either object literal or blocks, then the code I sampled suggests
that object literals as expression bodies are rather uncommon (only 16 out
of 5705 BTF candidates, or 0.2%).
// Not so bad...
x = ({ a: 123
That's the plan.
/be
Kevin Smith wrote:
If the consensus is that two arrows are too confusing, and we must
choose to prefer either object literal or blocks, then the code I
sampled suggests that object literals as expression bodies are rather
uncommon (only 16 out of 5705 BTF candidates, or
38 matches
Mail list logo
