On 21 April 2012 01:08, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are almost exactly the same
Andreas Rossberg wrote:
On 21 April 2012 01:08, Brendan Eichbren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
What I'm really pushing at here is the throw. Let's are used for
establishing and initializing bindings. From a binding perspective:
let x ;
and
let {x} = {};
are
Here are a few design alternates that have come up as I work the specification
draft for arrow functions
1) Always strict? Should all arrow functions be considered strict functions?
Pros
It's a new syntactic form, so it is it easy to make it be an implicit opt-in to
strict mode.
We generally
Andreas Rossberg wrote:
Clearly, it's not
possible to correct that, but why should that imply that all new
features need to inherit sloppy semantics, too?
There's no strict logical implication. On the plus side, the new
features are stricter (if you are pro-strict and anti-sloppy -- let's
Allen Wirfs-Brock wrote:
1) Always strict? Should all arrow functions be considered strict functions?
Pros
P1. It's a new syntactic form, so it is it easy to make it be an implicit
opt-in to strict mode.
P2. We generally want to encourage use of strict mode.
P3. If not, there would no way to
4) Should it be a dynamic error to try to use apply/call to set the this
binding of an arrow function.
Cons
To much existing code speculatively binding the this value when invoking
a function.
I propose that call/apply simply ignore the this value when invoked on an
arrow function.
What is the
I am in agreement with Angus on this one.
If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as bind,
On
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Angus Croll
Sent: Saturday, April 21, 2012 16:03
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: A few arrow function specification issues
4) Should it be a dynamic
I am in agreement with Angus on this one.
If there is no skinny arrow, hard |this| binding should not be part of the
spec. Fat arrow functions should default to lexical |this|, but if there is
no skinny arrow, it should not be a hard binding and call/apply should be
allowed, as well as
It's important, as someone who hands off an arrow function to another part
of the system, to ensure that `this` means what it meant while I was
originally writing the code. This guarantee is vital for predictability of
behavior. Consider
let mapped = array.map((el) = el * this.x)
If I
a function shouldn’t work radically (and silently!) different depending
on how it is invoked
every current JS function behaves exactly this way :-)
I'm painfully aware that I sound like a broken record on this, but
introducing a hard-bound function option while continuing to suport
dynamic-bound
a function shouldn’t work radically (and silently!) different depending on
how it is invoked
every current JS function behaves exactly this way :-)
`this` when not invoking a function as a method:
1. Bearable: this === undefined
2. Nasty: this === window
3. Very nasty: lexical this
I'm
On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer a...@rauschma.de wrote:
Counter-question: Isn’t it clear when you create a function whether it is
going to be a non-method function or a method?
It's clear to the implementer - Its not clear to a function that gets it as
an argument -
Angus Croll wrote:
On Sat, Apr 21, 2012 at 3:06 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
On Sat, Apr 21, 2012 at 1:56 PM, Axel Rauschmayer
a...@rauschma.de mailto:a...@rauschma.de wrote:
Counter-question: Isn’t it clear when you create a function
I would argue that – in ES.next – whenever a function is passed as an
argument, one should always assume that it is a non-method function and
completely ignore `this`.
This makes me sad. Seems like functions are going to be a little less first
class than they were before - and for fairly
I understand your argument, but I think it is more important to be able to
switch in full to the new function operator(s), not sometimes one, other
times the other.
Why? Arrow functions and traditional functions serve different semantic
purposes. Why is it important to you that we
Using `=` but being forced to using `function` anytime I want dynamic this
just doesn't work.
That may be the crux of the matter. I’d say: In new code, use a method
definition any time you want dynamic `this`. In old code, use a function
expression.
--
Dr. Axel Rauschmayer
a...@rauschma.de
Adding a firstIndex argument to string.search seems like an incomplete proposal
to me. IMO, if it were to be added there, it should also be added at least to
regexp.test, regexp.exec, and string.match when given a nonglobal regex (in
which case it’s an alias for regexp.exec). It could also be
18 matches
Mail list logo
