On 5 June 2012 00:56, Anton Kovalyov m...@kovalyov.net wrote:
On Monday, June 4, 2012 at 3:10 PM, Yehuda Katz wrote:
It's too late for jQuery to fix the order now. However, in the face of
arrows or bound functions, we probably could detect a user intent to use
`this` for their own purposes
On Mon, Jun 4, 2012 at 12:54 PM, Brendan Eich bren...@mozilla.com wrote:
Angus Croll wrote:
I actually agree. I included non-this methods only because reading
through this thread I got a feeling that there was some consensus that
they be treated differently. More than happy to not do that.
Andreas Rossberg wrote:
On 5 June 2012 00:56, Anton Kovalyovm...@kovalyov.net wrote:
On Monday, June 4, 2012 at 3:10 PM, Yehuda Katz wrote:
It's too late for jQuery to fix the order now. However, in the face of
arrows or bound functions, we probably could detect a user intent to use
`this`
On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich bren...@mozilla.com wrote:
What I perceive from the JSFixed effort, and from Angus who is good enough
to post here: people have a particular concern that fat-arrow is too sweet
and it will lure the children into the witch's house: passing fat
Russell Leggett wrote:
On Tue, Jun 5, 2012 at 12:36 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
What I perceive from the JSFixed effort, and from Angus who is
good enough to post here: people have a particular concern that
fat-arrow is too sweet and it
On Tue, Jun 5, 2012 at 12:56 PM, Russell Leggett
russell.legg...@gmail.comwrote:
I think that the dynamic |this| behavior of jQuery is not something that
should be encouraged. I understand it is probably mostly that way because
of the dom event api, but that doesn't change the fact that it
Yes the thread needs wrapping up. Maybe I can attempt summarize the dilemma
- with a question:
Is call/apply just a remedy for non-lexical this assignment? Or is it a
powerful feature in it own right.
I'm with the second camp, but I think I'm in the minority in this list
On Tue, Jun 5, 2012 at
Angus Croll wrote:
Is call/apply just a remedy for non-lexical this assignment? Or is it
a powerful feature in it own right.
This isn't a well-defined question. Do you mean powerful as in, must
be able to override |this| via the |thisArg| first parameter?
We know that's not possible even in
On Tue, Jun 5, 2012 at 2:30 PM, Angus Croll anguscr...@gmail.com wrote:
Yes the thread needs wrapping up. Maybe I can attempt summarize the
dilemma - with a question:
Is call/apply just a remedy for non-lexical this assignment? Or is it a
powerful feature in it own right.
I'm with the
I would also like to express that I think = with proposed (bound this)
semantics, are great. And I don't think it introduces any new issues it's just
a sugar for:
function() { /* … */ }.bind(this)
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Tuesday, 2012-06-05 at
On 3 June 2012 20:13, Angus Croll anguscr...@gmail.com wrote:
Not suggesting that arrow functions be special cased or that they ignore
|thisArg|. I'm suggesting for all relevant cases (=, bind and no |this|) we
only throw an error on call/apply if the |thisArg| is non null.
That would not only
I actually agree. I included non-this methods only because reading through
this thread I got a feeling that there was some consensus that they be
treated differently. More than happy to not do that.
On Mon, Jun 4, 2012 at 8:16 AM, Andreas Rossberg rossb...@google.comwrote:
On 3 June 2012
Angus Croll wrote:
I actually agree. I included non-this methods only because reading
through this thread I got a feeling that there was some consensus
that they be treated differently. More than happy to not do that.
You mean you still propose that (= 42).call({}) should throw, but
On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich bren...@mozilla.com wrote:
You mean you still propose that (= 42).call({}) should throw, but
(function () { return 42; }).call({}) should not?
Sorry, this isn't a principled response. There should be no difference in
result between those two
To be honest, I was mostly thinking about this feature from a jQuery
transition perspective.
Right now, callbacks to methods like `each` in jQuery expect to receive a
`this` binding for the current element in the iteration.
For example, in the case of `each`, the call signature looks like this:
Angus Croll wrote:
On Mon, Jun 4, 2012 at 9:54 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
You mean you still propose that (= 42).call({}) should throw, but
(function () { return 42; }).call({}) should not?
Sorry, this isn't a principled response. There
Yehuda Katz wrote:
I don't know whether it makes sense for a brand-new API to be designed
this way, but for APIs that presently make (possibly misguided) use of
`this` in place of a first parameter, the new (user-initiated, not
available in ES3) binding behavior provides a single shot at a
On Monday, June 4, 2012 at 3:10 PM, Yehuda Katz wrote:
It's too late for jQuery to fix the order now. However, in the face of arrows
or bound functions, we probably could detect a user intent to use `this` for
their own purposes and use that as a signal to change the order.
If I read
On Mon, Jun 4, 2012 at 6:10 PM, Yehuda Katz wyc...@gmail.com wrote:
snip
jQuery.each(someArray, function(i, item) {
// this and item are the items in the Array
// i is the index
});
It's too late for jQuery to fix the order now. However, in the face of
arrows or bound functions,
On Monday, June 4, 2012 at 6:56 PM, Anton Kovalyov wrote:
If I read the code correctly, it means that the same method will have
different signatures depending on the function form: $(*).each(function (i,
item) { … }); vs. $(*).each((item, i) = { … })
I can assure you that will
Angus Croll wrote:
To my mind (2) is the actual problem. To quote Yehuda the proposed
semantics interfere with more intentional uses of `call` and `apply`.
The followups have made it clear to me there is no such interference in
non-error cases. Users of call and apply who need to override
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote:
Angus Croll wrote:
To my mind (2) is the actual problem. To quote Yehuda the proposed
semantics interfere with more intentional uses of `call` and `apply`.
Users of call and apply who need to override |this| have as their
On Jun 2, 2012, at 23:14, Brendan Eich bren...@mozilla.org wrote:
So are you looking for an isBound predicate just to throw an error?
Sorry misread your question. Yes. For reasons stated.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Angus Croll wrote:
On Jun 2, 2012, at 23:14, Brendan Eichbren...@mozilla.org wrote:
Angus Croll wrote:
To my mind (2) is the actual problem. To quote Yehuda the proposed semantics
interfere with more intentional uses of `call` and `apply`.
Users of call and apply who need to override
Brendan Eich wrote:
Clarity depends on many things including how well documented or
commented the code -- especially that contract that we just agreed
exists -- might be.
One thing I forgot to write:
With array extras such as forEach, almost always the contract is local
and needs no docs
But that's exactly why we should be conservative about locking users into
hard bindings when their intentions are not clear (clear: 'bind' or no
|this| value, unclear: arrow functions). As someone who views call/apply as
cornerstones of the language and who's libraries depend on it, an
Angus Croll wrote:
But that's exactly why we should be conservative about locking
users into hard bindings when their intentions are not clear
(clear: 'bind' or no |this| value, unclear: arrow functions).
As someone who views call/apply as cornerstones of the
related: are explicitly bound functions going to get a 'target' reference
to the unbound function in ES6? I've manually set this property many times
(mainly for debugging)
On Thu, May 31, 2012 at 9:05 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 7:44 PM, David Herman
On Wed, May 30, 2012 at 2:01 PM, Rick Waldron waldron.r...@gmail.comwrote:
a means of detecting bound functions would essentially mitigate any
perceived pain points of fat-arrow-functions. If we can get consensus on
something like this, it would allay community concerns about the fat arrow.
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What guarantee are you trying to provide? What do you mean by might?
+1
I think
On May 31, 2012, at 2:27 AM, Andreas Rossberg wrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What guarantee are you
On 31 May 2012 18:03, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On May 31, 2012, at 2:27 AM, Andreas Rossberg wrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out)
On Thu, May 31, 2012 at 2:27 AM, Andreas Rossberg rossb...@google.comwrote:
On 31 May 2012 00:31, David Herman dher...@mozilla.com wrote:
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for
can. What
On Thu, May 31, 2012 at 12:51 PM, Mark S. Miller erig...@google.com wrote:
We do not complain that a safe program might need to be revised before a
type checker can vouch that it is safe.
As the author of a type checker, let me assure you that while you
might not complain, your users certainly
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
Contracts are much more useful if they are enforced by the
system, the language and runtime in this case.
Cheers - BIll
On 31 May 2012 19:01, Bill Frantz fra...@pwpconsult.com wrote:
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
Contracts are much more useful if they are enforced by the system, the
language and runtime
On Thu, May 31, 2012 at 1:32 PM, Andreas Rossberg rossb...@google.comwrote:
On 31 May 2012 19:01, Bill Frantz fra...@pwpconsult.com wrote:
On 5/31/12 at 2:27, rossb...@google.com (Andreas Rossberg) wrote:
A function is free to _document_ it as part of its
contract, though.
On May 31, 2012, at 11:13 AM, Russell Leggett wrote:
If you reframe the problem as |this| just being another parameter, this whole
debate seems quite silly to me. Any function that is written to have a |this|
value be dynamic, and possibly set by the caller can be rewritten as a
function
I think there's a core confusion at the heart of this thread. Let's restart
operationally.
If one did have such a predicate, when would some other program actually
use it? In other words, for the predicate you have in mind, please give a
concrete example where a program would usefully say
if
On Thu, May 31, 2012 at 5:40 PM, Mark S. Miller erig...@google.com wrote:
snip
If the predicate means what I think it should mean, I can offer some
examples of when I would do this. If the predicate means anything else
that's been advocated on this thread, such as fat arrow or bound, then I
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
I think there's a core confusion at the heart of this thread. Let's restart
operationally.
If one did have such a predicate, when would some other program actually use
it? In other words, for the predicate you have in mind, please give
If you are using call anyway and passing the array as thisObj there, why do
you need to do the bind at all?
--
John A. Tamplin
Software Engineer (GWT), Google
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, May 31, 2012 at 3:08 PM, Rick Waldron waldron.r...@gmail.comwrote:
I'm going to take a stab at this, because I think I have a good
understanding of what the JSFixed group is concerned about...
Hi Rick, thanks. That's exactly what I was hoping for.
// Imaginary DOM library
DOM
On Thu, May 31, 2012 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
For example, somebody might want to replace the existing apply, call, and
bind methods, with versions that throw an error when invoked on a fat arrow
or bound function. For example:
(function replaceCall() {
On May 31, 2012, at 4:17 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 3:14 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
For example, somebody might want to replace the existing apply, call, and
bind methods, with versions that throw an error when invoked on a fat arrow
or
On Thu, May 31, 2012 at 7:01 PM, Mark S. Miller erig...@google.com wrote:
snip
// Imaginary DOM library
DOM = {};
// This function accepts a function as it's second argument,
// what happens when its a bound function? I'd like write the
// API in a way that is friendly to both types of
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Wouldn't this mean that fat arrow functions inherit call, apply and bind
as well? (I may have misunderstood this aspect)
I believe they do.
Yes, sorry, that is a typo - I put this example together quickly, I
On Thu, May 31, 2012 at 4:44 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I don't think I argued that for isBound although I certainly would make
that argument about arrow functions in general.
In this case, I'm assuming a debugging scenario. Somebody is passing arrow
functions through
Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have misunderstood this aspect)
I believe they do.
Yes, and both
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have misunderstood this aspect)
I believe they do.
Yes, and both apply and call are useful on arrows, even though |this|
cannot be overridden. Arguments still matter ;-).
My previous
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.com wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Could you post a corrected example? Thanks.
To reduce any confusion, I've posted the corrected code here:
https://gist.github.com/2847608
Rick
On Thu, May 31, 2012 at 5:41 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.comwrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.comwrote:
Could you post a corrected example? Thanks.
To reduce any
On May 31, 2012, at 5:31 PM, Brendan Eich wrote:
Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:55 PM, Rick Waldron waldron.r...@gmail.com
mailto:waldron.r...@gmail.com wrote:
Wouldn't this mean that fat arrow functions inherit call, apply
and bind as well? (I may have
On May 31, 2012, at 5:18 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 4:44 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I don't think I argued that for isBound although I certainly would make that
argument about arrow functions in general.
In this case, I'm assuming a
On Thursday, May 31, 2012 at 8:49 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 5:41 PM, Rick Waldron waldron.r...@gmail.com
(mailto:waldron.r...@gmail.com) wrote:
On Thu, May 31, 2012 at 8:11 PM, Mark S. Miller erig...@google.com
(mailto:erig...@google.com) wrote:
On
On Thu, May 31, 2012 at 6:06 PM, Rick Waldron waldron.r...@gmail.com wrote:
The original API allowed me to pass an explicitly bound callback (whether it
was by bind or fat arrow) and have that binding take precendence over a
default behavior.
Hi Rick, I don't understand that sentence. Can you
On Thu, May 31, 2012 at 5:56 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If I understood it, I would probably prefer what you are proposing.
However, I suspect that many JS programs will conceptually equate bond
this with bound functions and arrow functions and not think about equating
On May 31, 2012, at 7:23 PM, Mark S. Miller wrote:
On Thu, May 31, 2012 at 5:56 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
If I understood it, I would probably prefer what you are proposing.
However, I suspect that many JS programs will conceptually equate bond
this with bound
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Mark S. Miller
Sent: Thursday, May 31, 2012 22:24
Non-strict mode is so bizzarre that I wouldn't be surprised, but I can't
think of an example. Is my proposed rule unsound
On May 31, 2012, at 6:06 PM, Rick Waldron wrote:
The original API allowed me to pass an explicitly bound callback (whether it
was by bind or fat arrow) and have that binding take precendence over a
default behavior.
I think you might still be missing a key point: if `callbackFn` is a bound
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should mean, I can offer some examples
of when I would do this.
Could you? I
FWIW, I tried very hard to come up with an example but failed. If I understand
it correctly fat arrow acts is a helper for `var self = this`. Then it no
matter what the underlying method does the following code will simply ignore
`this`:
var self = this;
DOM.each(div, function (el) {
On Thu, May 31, 2012 at 10:42 PM, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 6:06 PM, Rick Waldron wrote:
The original API allowed me to pass an explicitly bound callback
(whether it was by bind or fat arrow) and have that binding take
precendence over a default behavior.
Yes, you're exactly right - I hadn't realized this would be the behavior
-- but it makes perfect sense seeing it from a different perspective.
By different, I mean correct ;)
Rick
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, May 31, 2012 at 7:44 PM, David Herman dher...@mozilla.com wrote:
On May 31, 2012, at 2:40 PM, Mark S. Miller wrote:
if (isBoundOrWhateverWeCallIt(f)) {
//... do something
} else {
//... do something else
}
If the predicate means what I think it should
On May 29, 2012, at 10:05 PM, Rick Waldron wrote:
On Wednesday, May 30, 2012 at 12:00 AM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes
On Wed, May 30, 2012 at 10:32 AM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On May 29, 2012, at 10:05 PM, Rick Waldron wrote:
On Wednesday, May 30, 2012 at 12:00 AM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at
Allen Wirfs-Brock wrote:
From that perspective I think isThisBound or just isBound is how
most people will think about it.
I think isBound wins in light of F.p.bind.
If you want to reverse the sense, I think it would be something like
hasDynamicThis or perhaps even isMethod (where by
On May 29, 2012, at 9:00 PM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right
On May 30, 2012, at 2:18 PM, Mark S. Miller wrote:
However, there might be some utility (at least for debugging) in having a
Function.prototype.isThisBound method. It would return true for arrow
functions and functions created via Function.prototype.bind
I agree that such a predicate
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor complete (as I pointed out) for can.
What guarantee are you trying
It is sound, as corrected in light of Allen's post. If the function
contains a direct eval operator in its body, it also might sense this.
On Wed, May 30, 2012 at 3:31 PM, David Herman dher...@mozilla.com wrote:
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm
On Wednesday, May 30, 2012 at 6:31 PM, David Herman wrote:
On May 30, 2012, at 3:23 PM, Mark S. Miller wrote:
Independent of name, I'm trying to test for might sense this.
OK, but that begs the question. The problem is that your might test is
neither sound (as Allen pointed out) nor
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right with me.
Why should an arrow function be treated any differently than an explicitly
bound function (ie, via bind)?
--
All soft-bind proposals I have heard have failed to get traction for
two reasons:
1. Binding |this| makes an abstraction with its own integrity.
Overriding the |this| binding only some of the time violates that
abstraction.
2. Implementations including beloved V8 and venerable SpiderMonkey
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com wrote:
I'm not sure if this makes sense, but something about breaking `call` and
`apply` doesn't sit right with me.
Why should an arrow function be treated
On Wednesday, May 30, 2012 at 12:00 AM, Russell Leggett wrote:
On Tue, May 29, 2012 at 11:52 PM, John Tamplin j...@google.com
(mailto:j...@google.com) wrote:
On Tue, May 29, 2012 at 11:50 PM, Yehuda Katz wyc...@gmail.com
(mailto:wyc...@gmail.com) wrote:
I'm not sure if this makes
77 matches
Mail list logo
