On Mar 16, 2013, at 7:40 PM, Brendan Eich wrote:
>
> Object.is() // true
>
> It has a nice existentialist ring to it!
>
perfect for when you "u" or "r" key is broken
allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/l
Allen Wirfs-Brock wrote:
On Mar 16, 2013, at 5:02 PM, Tom Schuster wrote:
Also note that with the current definition Object.is() should return
true. I am not really a big fan of that ;)
All standard function have a well specified, but perhaps odd, behavior when no
arguments are passed to the
That conversation on `fn. caller` left me many doubts about extra things
too.
As example, I understand the fact a function that do not want to be
accessed should not be accessed when any accepted object could due tweaked
to retrieve it via caller, that's OK, but what about private "classes" and
th
It's certainly plausible that an implementation could do the analysis to
recognize this pattern and implement it so there isn't an extra allocation or
any extra copying.
It it became an common perf. bottleneck you might expect the better
implementation to do so. If it isn't a common perf. issu
Would using (...args) incur a performance penalty and impair
optimization since the argument list has to be an array now? Or is
that still better than using 'arguments.length'? Enforcing arity is a
common enough (and important, IMO) pattern that I'd be wary of doing
it using a pattern that is going
On Mar 17, 2013, at 1:17 , Allen Wirfs-Brock wrote:
> If you need to do arity analysis of parameter but also what to apply default
> values, destructuring, etc I would do the following:
>
> Instead of
>function ([a,b], c,d=5, ...rest) {...}
> do
>function (...args) {
>if (args.l
If you need to do arity analysis of parameter but also what to apply default
values, destructuring, etc I would do the following:
Instead of
function ([a,b], c,d=5, ...rest) {...}
do
function (...args) {
if (args.length <3) throw Error("too few arguments");
let [[a,b], c,d=5,
On Mar 16, 2013, at 5:02 PM, Tom Schuster wrote:
> Also note that with the current definition Object.is() should return
> true. I am not really a big fan of that ;)
All standard function have a well specified, but perhaps odd, behavior when no
arguments are passed to them. It's just how JavaSc
On Sat, Mar 16, 2013 at 4:53 PM, Brendan Eich wrote:
> Jason Orendorff wrote:
>
>> Functions with default arguments have the same weird problem. You can
>> still do it in one pass, but you have to track "this
>> parameter-default-value-**expression contains code that would not be
>> allowed if th
On Mar 16, 2013, at 4:49 PM, Axel Rauschmayer wrote:
> Has using more powerful function/method signatures ever been a consideration
> for the spec? For example, type annotations could replace imperative
> coercions.
I am applying ES6 style default value and rest parameter conventions to the
Also note that with the current definition Object.is() should return
true. I am not really a big fan of that ;)
On Sun, Mar 17, 2013 at 12:56 AM, Allen Wirfs-Brock
wrote:
>
> On Mar 16, 2013, at 4:42 PM, Tom Schuster wrote:
>
>> I would argue that the disclaimer makes this more confusing. I am
>>
What is the recommended way of enforcing arity under ECMAScript 6 (while
avoiding arguments.length)?
Two ideas:
1. Parameter default value is a function call that throws an exception. Not
sure if that works.
function foo(required = throwAnException(), optional) { ... }
2. Introduce a postfix `
On Mar 16, 2013, at 4:42 PM, Tom Schuster wrote:
> I would argue that the disclaimer makes this more confusing. I am
> aware of the behavior that not passed parameters are undefined. But It
> sounded like we would never execute step 1. when the parameter count
> doesn't match. And thus leaving th
Jason Orendorff wrote:
Functions with default arguments have the same weird problem. You can
still do it in one pass, but you have to track "this
parameter-default-value-expression contains code that would not be
allowed if the enclosing function turns out to be strict". You won't
know that it
The meeting notes say:
> arrows can't have intrinsic names (contrast with NFEs) so arguments.callee
> may be wanted, so arrows should not be strict-only.
>
>
I'm glad this is going away. I share Alex's skepticism over this particular
motive. But just generally it was going to be a little bizarre a
Has using more powerful function/method signatures ever been a consideration
for the spec? For example, type annotations could replace imperative coercions.
On Mar 17, 2013, at 0:01 , Allen Wirfs-Brock wrote:
> On Mar 16, 2013, at 11:18 AM, Tom Schuster wrote:
>
>> Looking at the the steps fo
I would argue that the disclaimer makes this more confusing. I am
aware of the behavior that not passed parameters are undefined. But It
sounded like we would never execute step 1. when the parameter count
doesn't match. And thus leaving the result of the call not defined.
On Sun, Mar 17, 2013 at
I understand, but it's still a limitation of arrow functions that they rely on
arguments.callee to self-reference. Relying on the defined name they're
assigned to suffers from the "can be redefined" problem. NFE's don't suffer
this problem and can completely avoid `arguments` in ES6 for all use
On Mar 16, 2013, at 3:27 PM, Brendan Eich wrote:
> Axel Rauschmayer wrote:
>> Quoting
>> https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
>>
>>> Consensus on... Stay the course on spec development approach Class, Modules
>>> implicitly strict. Arrows not strict Sustaining
Allen Wirfs-Brock wrote:
regarding using 'arguments' within arrow functions, I would be
sympathetic if somebody wanted to argue that arrow functions should
treat 'arguments' similar to this and super and not local rebind its
meaning.
However, I would also anticipate some implementor push back
If you need to name an arrow function you can use let or const and reference
the name both within body and use it as an argument expression.
regarding using 'arguments' within arrow functions, I would be sympathetic if
somebody wanted to argue that arrow functions should treat 'arguments' simila
On Mar 16, 2013, at 3:40 PM, David Bruant wrote:
> Le 16/03/2013 19:18, Tom Schuster a écrit :
>> Hey!
>>
>> Looking at the the steps for Object.is the first sentence just says:
>>> "When the is function is called with arguments value1 and value2 the
>>> following steps are taken:"
>> I don't r
On Mar 16, 2013, at 11:18 AM, Tom Schuster wrote:
> Hey!
>
> Looking at the the steps for Object.is the first sentence just says:
>> "When the is function is called with arguments value1 and value2 the
>> following steps are taken:"
> I don't remember other functions being defined like that. It
Le 16/03/2013 19:18, Tom Schuster a écrit :
Hey!
Looking at the the steps for Object.is the first sentence just says:
"When the is function is called with arguments value1 and value2 the following steps
are taken:"
I don't remember other functions being defined like that. It should at
least s
Axel Rauschmayer wrote:
Quoting
https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
Consensus on... Stay the course on spec development approach Class,
Modules implicitly strict. Arrows not strict Sustaining our position
on the handling of let ambiguities (Note: this is a l
OK. Thankfully, with `super`, an important use case for a function referring to
itself goes away (AFAIK, `super` keeps qooxdoo and Ember in non-strict mode,
they need arguments.callee).
On Mar 16, 2013, at 23:12 , Brendan Eich wrote:
> I wouldn't overreact. My note was simply that we should no
I wouldn't overreact. My note was simply that we should not make arrows
strict by definition, and TC39 agreed. Among the "folk wisdom" reasons
for avoiding strict is to have arguments.callee, but of course NFEs
should be preferred in modern engines. But there's no arrow NFE form.
/be
Brandon
I think this is a better argument for introducing a new primitive for
referencing the current function than for resurrecting arguments.
On Mar 16, 2013, at 2:29 PM, Axel Rauschmayer wrote:
> Quoting Brendan Eich in [1]:
>
>> arrows can't have intrinsic names (contrast with NFEs) so arguments.c
Quoting Brendan Eich in [1]:
> arrows can't have intrinsic names (contrast with NFEs) so arguments.callee
> may be wanted, so arrows should not be strict-only.
Is this really an option? Sounds messy. Like a carrot to go back to non-strict.
I’d either allow arguments.callee in both modes. Or int
Quoting https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-30.md
> Consensus on... Stay the course on spec development approach Class, Modules
> implicitly strict. Arrows not strict Sustaining our position on the handling
> of let ambiguities (Note: this is a local consensus).
I’m
Sorry for the typo in the title :)
On Sat, Mar 16, 2013 at 7:18 PM, Tom Schuster wrote:
> Hey!
>
> Looking at the the steps for Object.is the first sentence just says:
>> "When the is function is called with arguments value1 and value2 the
>> following steps are taken:"
> I don't remember other
Hey!
Looking at the the steps for Object.is the first sentence just says:
> "When the is function is called with arguments value1 and value2 the
> following steps are taken:"
I don't remember other functions being defined like that. It should at
least say something along the lines of
"When called
32 matches
Mail list logo
