In fact, without |, are there any cases where super behaves correctly in
an object literal, other than making super calls to Object.prototype
functions?
We haven't eliminated the ability to define object literals that inherit from
objects other than Object.prototype. We have just
Luke Hoban wrote:
In fact, without|, are there any cases where super behaves
correctly in an object literal, other than making super calls to
Object.prototype functions?
We haven't eliminated the ability to define object literals that
inherit from objects other than Object.prototype. We
Thanks Dave,
Of the 3 use cases you mentioned, I think unique names are probably
sufficient for 1 and 3. For the second use case (an inaccessible piece of
data associated with an object), would not a weak map also be appropriate?
So far I don't see that the benefit of private names (as opposed
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
Kevin Smith wrote:
Thanks Dave,
Of the 3 use cases you mentioned, I think unique names are probably
sufficient for 1 and 3. For the second use case (an inaccessible
piece of data associated with an object), would not a weak map also be
appropriate?
No, WeakMaps have two problems we've
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
14 matches
Mail list logo
