On Fri, Mar 30, 2012 at 4:46 AM, Felix Böhm esdisc...@feedic.com wrote:
How about a loose-bound |this|, so that the function falls back to the
bound |this| instead of the global scope when no other options are
available (or `null` or `undefined` are passed to `.apply/.bind/.call`)?
I
3. Are parenthese required for zero arguments or will
let a = = doThis();
syntax be permitted (in line with CS)
This too is clearly specified by
http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax#grammar_changes
ArrowFormalParameters, second right-part.
That seems
Not given. TC39ers (not all, just ones near me) started blenching (or is
it blanching? no, blenching). The issue was muddled because the optional
body-block was mixed in (i.e., the minimal arrow function, as in
CoffeeScript, was just |=| in the previous version of the strawman).
As I've said
As I've said a couple of times here, we could try again to reach consensus on
making () as empty arrow formal parameter list optional,
Seems useful, but not worth upsetting anyone over.
and separately consider making an empty body-block optional.
Sorry if I missed this, but: What would
Kevin Smith wrote:
I like your new(){}/static(){} idea at a glance. Need to ruminate
(moo!) on it at length.
I can't give you a use case (it's just a felling of being a good design
thing), but I would like the classes be higher-level construct based on
low-level ones. If
Angus Croll wrote:
On Fri, Mar 30, 2012 at 4:46 AM, Felix Böhm esdisc...@feedic.com
mailto:esdisc...@feedic.com wrote:
How about a loose-bound |this|, so that the function falls back to
the bound |this| instead of the global scope when no other options
are available (or `null` or
On Apr 8, 2012, at 4:00, Herby Vojčík he...@mailbox.sk wrote:
No special cases for null or undefined, please.
Fine. Then we should just default to lexical binding for standalone function
calls - I'll stick my neck out and assert that it's the only area that needs
fixing with respect to
I don't see anything that is broken by arrow functions. You are
attempting to use arrows for defining methods which is incorrect.
Sorry, I obfuscated unnecessarily by making the inner functions into arrows
too.
But the important one is the withCircleUtilsFat function which is not a
method
Which form has more brevity, then?
// This?
var withCircleUtilsFat = () = { ... };
// Or this?
function withCircleUtilsFat() { ... };
In any case, between object literal methods and arrow functions, I think
you'll find that the vast majority of your function expressions will get
I can't give you a use case (it's just a felling of being a good design
thing), but I would like the classes be higher-level construct based on
low-level ones. If new()/static() gets in, it defines its own exclusive
semantics not possible to do by plain constructor
I agree in general, but
But isn’t a clear separation of responsibility better?
Want a constructor = use a class declaration.
Want a callable = use an arrow function.
I always disliked that some functions in ECMAScript 5 can be invoked as either
a function or a constructor. What would you want an entity Foo for that
I always disliked that some functions in ECMAScript 5 can be invoked as
either a function or a constructor. What would you want an entity Foo for
that can be invoked in two ways? E.g.:
new Foo(...)
Foo(...)
Maybe Brendan can answer that one? : )
Seriously, though, it's a fair
Ha! nice catch :-)
My concern is with developers not knowing about the side effects of = and
therefore when to use it.
On Sun, Apr 8, 2012 at 4:09 PM, Kevin Smith khs4...@gmail.com wrote:
Which form has more brevity, then?
// This?
var withCircleUtilsFat = () = { ... };
// Or
13 matches
Mail list logo
