A bit on Object.extend(obj,{...}) vs. obj.{...}
To get started, just a reminder that we can't really compare the two based on
the assumption that the second argument to extend is an object literal as there
is no way to syntactically guarantee that. We have to assume that both
arguments to
Axel Rauschmayer wrote:
I am not saying that the transition from the old rules to the new rules will be
entirely painless, but if the new rules are simple, that pain is worth it, IMHO.
There are no new rules. Some functions ignore |this| or bind it rather
than using it. These differences in
With “rules”, I don’t mean rules in the sense of the language spec, but rather
rules for teaching the language to newcomers.
On Apr 29, 2012, at 10:28 , Brendan Eich wrote:
Axel Rauschmayer wrote:
I am not saying that the transition from the old rules to the new rules will
be entirely
On Apr 28, 2012, at 22:24, Axel Rauschmayer a...@rauschma.de wrote:
The following two rules should be everything one has to know regarding
callable entities, in ES.next:
1. Method: `this` is an implicit parameter = use a method definition.
2. Non-method function: `this` is not an
On Apr 29, 2012, at 1:28, Brendan Eich bren...@mozilla.org wrote:
Axel Rauschmayer wrote:
I am not saying that the transition from the old rules to the new rules will
be entirely painless, but if the new rules are simple, that pain is worth
it, IMHO.
There are no new rules. Some
If I understand correctly, this approach negates the need for a mixin
function entirely - localStorage could just be an old style mixin hash.
But either way this tosses out the benefits I get from functional mixins. By
invoking the mixin instead of copying it I can a) customize it's
1- Yes, several time that you mention it, and ++ from me each time
2- I prefer the dot notation rather than Object.extend, even if both are
good
Le 28/04/2012 20:49, Kevin Smith a écrit :
Hi Angus!
1) Kevin et al suggested YAGN call/apply on (non-method)
functions. Here's a pretty
If so then there is no need for any isArrowFunction or
isFunctionThatBindsOrIgnoresThis predicate.
/be
Axel Rauschmayer wrote:
With “rules”, I don’t mean rules in the sense of the language spec,
but rather rules for teaching the language to newcomers.
Angus Croll wrote:
On Apr 29, 2012, at 1:28, Brendan Eichbren...@mozilla.org wrote:
Axel Rauschmayer wrote:
I am not saying that the transition from the old rules to the new rules will be
entirely painless, but if the new rules are simple, that pain is worth it, IMHO.
There are no new
Brendan Eich wrote:
But the lexical part doesn't enter into the contract of the API taking
the function argument. It's between the API caller and the function
argument's implementation -- when the latter is a closure in the
former, lexical |this| often wins.
What does enter into the
Then I guess we need another survey.
What does the JS arrow function proposal mean to you?
a) An abbreviated function syntax
b) A hard bound lexical |this| binding
c) Nothing
I'd gladly be proved wrong but my guess is most JS developers who don't
answer (c) will answer (a). (I see plenty of
Use case: error checks. For example: forEach could complain if it got both an
arrow function and a thisValue. One could also complain if one expected a
function with dynamic/unbound `this` and got a function with bound `this`,
instead. To be extra strict, one could even complain when an unbound
Angus Croll wrote:
Then I guess we need another survey.
What was the first survey?
Kevin's analysis was on code, using a tool to classify functions as
no-this/lexical-this vs. the rest.
What does the JS arrow function proposal mean to you?
a) An abbreviated function syntax
b) A hard bound
Axel Rauschmayer wrote:
Use case: error checks. For example: forEach could complain if it got
both an arrow function and a thisValue.
Do you mean error, or warning?
Because you can use forEach with a function that ignores its |this|, and
pass the thisValue optional parameter too, without
I'm sorry that I could not reply to the multiple replies I got last
weekend. Simply can't get the time - plus I have a phobia of fan-out
replies (an issue with mail-based discussion groups?)
In any case here's a potted reply that addresses at least some of the
points:
1) Kevin et al suggested
Hi Angus!
1) Kevin et al suggested YAGN call/apply on (non-method) functions. Here's
a pretty neat example where call/apply is a perfect fit for standalone
functions - and would break if replaced with fat arrows.
https://gist.github.com/2520731
This is a great example. Two points:
1.) In
Kevin Smith wrote:
2.) For mixin stuff like your example, I think the elegant solution is
object literal extension syntax:
https://gist.github.com/2521128
I'm not sure of the status of that syntax, but hopefully it will get
included in ES6.
What if the ES6 solution were a standardized
What if the ES6 solution were a standardized Object.extend, instead?
https://gist.github.com/2523106
(Assuming the same semantics...)
It's a little more wordy but still looks pretty good to me for this use
case.
kevin
___
es-discuss mailing list
On Sat, Apr 28, 2012 at 11:13 AM, Angus Croll anguscr...@gmail.com wrote:
1) Kevin et al suggested YAGN call/apply on (non-method) functions. Here's a
pretty neat example where call/apply is a perfect fit for standalone
functions - and would break if replaced with fat arrows.
Tab Atkins Jr. wrote:
This should rightly use 'function' (which is meant for methods), or
eventually use a mixin syntax.
See the version Kevin did using Object.extend and method definition
shorthand:
https://gist.github.com/2523106
/be
___
The following two rules should be everything one has to know regarding callable
entities, in ES.next:
1. Method: `this` is an implicit parameter = use a method definition.
2. Non-method function: `this` is not an implicit parameter = use an arrow
function.
In this light, I’d rewrite Kevin’s
Correction:
Some code such as `forEach` implementations that previously needed to use
`call` to simulate lexical scoping don’t need the `thisValue` parameter for
arrow [was: array] functions.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog:
On Mon, Apr 23, 2012 at 3:36 PM, David Herman dher...@mozilla.com wrote:
I'm much more sympathetic to the idea of having *two* shorter-function
syntaxes, one optimized for methods and one optimized for non-method
functions. I understand the concern about bloat, but to me it addresses the
On Tue, Apr 24, 2012 at 12:33 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Apr 23, 2012 at 3:36 PM, David Herman dher...@mozilla.com wrote:
I'm much more sympathetic to the idea of having *two* shorter-function
syntaxes, one optimized for methods and one optimized for non-method
Seems like a typo and Tab’s got it right. The advantage of a thin arrow (over a
method definition) here is that you can do an implicit return and have slightly
less to type. Given that method definitions don’t appear inside statements, I
don’t see that as a problem.
AFAIK, an implicit return
On Tue, Apr 24, 2012 at 9:51 AM, Rick Waldron waldron.r...@gmail.com wrote:
When I read this, I assumed it was a reference to
this: http://wiki.ecmascript.org/doku.php?id=harmony:object_literals#object_literal_property_shorthands
Which would produce a method named set on box
box.set(42)
On Tue, Apr 24, 2012 at 1:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Apr 24, 2012 at 9:51 AM, Rick Waldron waldron.r...@gmail.com
wrote:
When I read this, I assumed it was a reference to
this:
3. Method dynamically attached to an object - here we don't have
special syntax, so we'll still need to use the function keyword.
Not necessarily. Object literal extensions are a possibility here,
especially if you are attaching more than one method:
obj.{
addMethodA() { ... },
Rick Waldron wrote:
I think the colon was just a typo
Dave is not cc'ed and may have missed the responses going back to Tab's
first one, but I think there was no typo. Dave's example:
box = {
_value: 0,
get: () - this._value,
set(v) { this._value = v }
}
Tab Atkins Jr. wrote:
The only case that isn't receiving special syntax (and thus which
could potentially benefit from a dynamic-this thin-arrow function) is
#3. However, while #3 is commontoday, #1 and #2 will eat most of its
share. I'm not sure that the remaining #3 cases will be worth a
On Tue, Apr 24, 2012 at 4:21 PM, Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
I think the colon was just a typo
Dave is not cc'ed and may have missed the responses going back to Tab's
first one, but I think there was no typo. Dave's example:
box = {
_value: 0,
On Apr 24, 2012, at 9:51 AM, Rick Waldron wrote:
On Tue, Apr 24, 2012 at 12:33 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Apr 23, 2012 at 3:36 PM, David Herman dher...@mozilla.com wrote:
box = {
_value: 0,
get: () - this._value,
set(v) { this._value
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this) functions.
(Edit: Oh, I see, leaning on the completion value of thin-arrow
functions here lets you shave a few characters off. The readability
loss of mixing the two
On Apr 24, 2012, at 1:40 PM, David Herman wrote:
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this)
functions.
(Edit: Oh, I see, leaning on the completion value of thin-arrow
functions here lets you shave a few
I believe that we could grammatically use ArrowBody as the body of concise
methods in object literals and classes. In that case, Dave's example could
be expressed as:
box = {
_value: 0,
unbox() ()- this._value,
setbox(v) this._value = v
}
That would
Allen Wirfs-Brock wrote:
unbox() ()- this._value,
Left-over ()- in the middle, right?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Apr 24, 2012, at 2:09 PM, Allen Wirfs-Brock wrote:
On Apr 24, 2012, at 1:40 PM, David Herman wrote:
On Apr 24, 2012, at 10:03 AM, Tab Atkins Jr. wrote:
There doesn't seem to be a need there for thin-arrow (dynamic this)
functions.
(Edit: Oh, I see, leaning on the completion value
On Apr 24, 2012, at 2:44 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
unbox() ()- this._value,
Left-over ()- in the middle, right?
yes, that's right. it should be
unbox () this.value,
I was actually confusing that example with something
thunk () () = this._value,
B. add expression bodies to method shorthands, don't add skinny arrow
(-) Loses the flexibility of shorthand syntax for assigning to an
existing object, a Tab pointed out. (Sorry Axel, mustache is not particularly
Harmonious.)
Sorry to hear that. _.extend(), then (by whichever name)?
On Apr 24, 2012, at 3:30 PM, Axel Rauschmayer wrote:
B. add expression bodies to method shorthands, don't add skinny arrow
(-) Loses the flexibility of shorthand syntax for assigning to an
existing object, a Tab pointed out. (Sorry Axel, mustache is not
particularly Harmonious.)
Using a builtin function (as opposed to an operator) would be less problematic
if one could invoke it infix, e.g.:
this (extend) { x: x, y: y }
But I guess deciding on that will have to wait until operator overloading gets
figured out.
On Apr 25, 2012, at 0:43 , Allen Wirfs-Brock wrote:
On Apr 24, 2012, at 3:53 PM, Axel Rauschmayer wrote:
Using a builtin function (as opposed to an operator) would be less
problematic if one could invoke it infix, e.g.:
this (extend) { x: x, y: y }
That wouldn't address the issues concerning cloning private names, super
binding, etc.
I wasn't convinced at first but I think the obj.{ ... } extension syntax
provides good utility. I would strongly suggest not giving it up. I've
used it in several refactoring examples on this list.
And I still don't see the attraction of thin arrow. It provides no
semantic benefit and only
Despite making repeated arguments for soft binding, I'm pretty sure I haven't
outlined here what it actually would *be*. Now that we're looking to add
syntactic forms that create bound function objects (arrows and class methods),
perhaps it's time to get consensus for or against. Soft binding
I'm not sure I understand the reasoning behind soft-binding. If I use
arrow syntax, my intention is to close over |this|. Allowing a caller to
change the binding of |this| will result in a violation of that closure.
In this respect, |this| within an arrow function is no different that any
other
On Mon, Apr 23, 2012 at 6:53 AM, Alex Russell a...@dojotoolkit.org wrote:
Despite making repeated arguments for soft binding, I'm pretty sure I
haven't outlined here what it actually would *be*. Now that we're looking
to add syntactic forms that create bound function objects (arrows and class
On Mon, Apr 23, 2012 at 2:47 PM, Russell Leggett
russell.legg...@gmail.com wrote:
On Mon, Apr 23, 2012 at 6:53 AM, Alex Russell a...@dojotoolkit.org wrote:
Despite making repeated arguments for soft binding, I'm pretty sure I
haven't outlined here what it actually would *be*. Now that we're
Yeah, I think you're missing the composition arguments. If I create
mixins with methods, they're going to have a promiscuious this as a
*feature*. You might not write code like this today, but you probably
should ;-)
But anyone who understands the language would not use arrow functions for
On Mon, Apr 23, 2012 at 6:46 AM, Kevin Smith khs4...@gmail.com wrote:
I'm not sure I understand the reasoning behind soft-binding. If I use
arrow syntax, my intention is to close over |this|. Allowing a caller to
change the binding of |this| will result in a violation of that closure.
In
On Apr 23, 2012, at 16:17 , Alex Russell wrote:
Having done this dance a couple of times, let me suggest to you that
the method form will *eventually* end up at a per-class getter on the
prototype which vends an instance function which is bound. People will
(reasonably) want binding of some
On Mon, Apr 23, 2012 at 3:53 AM, Alex Russell a...@dojotoolkit.org wrote:
The new forms we're adding (methods and arrows) have the potential to
change this radically, causing a large percentage of functions encountered
by programmers to have binding. If that binding is hard-binding, .call()
The semantic of Function.prototype.bind() precludes it. If we could
relax that to be effectively soft-bound, I'm *completely* on board,
but I expect it will cause some problems.
We could, of course, try this out in Chrome and see how it goes.
On Mon, Apr 23, 2012 at 4:32 PM, John J Barton
On Apr 23, 2012, at 8:32 AM, John J Barton wrote:
On Mon, Apr 23, 2012 at 3:53 AM, Alex Russell a...@dojotoolkit.org wrote:
The new forms we're adding (methods and arrows) have the potential to change
this radically, causing a large percentage of functions encountered by
programmers
On Apr 23, 2012, at 3:30 PM, Russell Leggett wrote:
That is only true for functions that actually use |this|. Even though bind
is probably not used in force yet because of cross-browser worries, var
self = this is used everywhere. Functions using that pattern are no more
usable with
The real use case that I constantly run into has nothing to do with binding
at all, rather the need for Function.prototype.partial and *no specific
binding*. The primary use case for soft binding or dynamic non-method
binding, as mentioned above, is the event callback and that's weird
semantic
On Apr 23, 2012, at 11:17 AM, Brendan Eich wrote:
Apologies for sounding schizo. I'm saying prototypal wins at scale and I see
it more often used, but closure has its fans and it's used too.
With both (plus other approaches such as Angus's) I do not think it's a given
that in the future,
Allen Wirfs-Brock wrote:
This seems like an important idiomhat may become even more important in the
context of ES6. We probably need to encourage broader education about this
idiom. But it isn't clear that it needs special syntax or even what that might
be.
Dave wrote
Brendan Eich wrote:
No, in any such prototype-getter-makes-bound-function scenario, we
would need memoization, so that
o.m === o.m
(Edit: I see you mention this below.)
The real problem is better captured by showing the prototype p and two
instances, o and q:
p.m === p.m
should be
On Apr 23, 2012, at 3:53 AM, Alex Russell wrote:
This means that most users of most functions can still use .call() and
.apply() without apprehension. Functions are still just functions.
You're assuming your conclusion: that there's some sort of platonic ideal
(just functions) of JS
59 matches
Mail list logo
