/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for FormalParameterList and
ArgumentList in the spec, implementations, and user's minds. I would
prefer to have elision, hole preservation, and defaulting based on
input array length rather than holes, but only if they were
consistently applied.
Thanks,
Sean Eagan
___
es
better
would be let! //...}
and:
f(a, , c, ...d)
would desugar to:
Function.prototype.apply.call(f, undefined, [a, , c, ...d]);
On Wed, Oct 5, 2011 at 2:19 PM, Sean Eagan seaneag...@gmail.com wrote:
On Mon, Oct 3, 2011 at 4:37 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
apply supports holes
/mozilla/mozilla-central/js/src/jsval.h.html#l259
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Oct 4, 2011 at 4:09 PM, Sean Eagan seaneag...@gmail.com wrote:
On Mon, Oct 3, 2011 at 5:11 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
as it currently stands, a function is allowed to use both:
function f(a,b,c,...rest) {
g(...arguments);
h(...rest);
}
Rest
as it is at the assignment boundary.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
the `arguments` object, so they could, and in
my view, should preserve holes for both Function.prototype.apply and
foo(...args) activations, at least if array structuring and
destructuring preserve holes as currently specified in the ES.next
draft spec.
Thanks,
Sean Eagan
On Mon, Oct 3, 2011 at 11:31 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Oct 3, 2011, at 6:49 AM, Sean Eagan wrote:
So I realized hole preservation is actually relevant in both array
structuring and destructuring. Array structuring and destructuring
ellipses forms are both
On Mon, Oct 3, 2011 at 11:35 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
But Function.prototype.apply doesn't preserve holes.
Function.prototype.apply
since the `undefined`
values don't need to be added to the rest parameter argument.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
element lists, by allowing them to have holes (e.g.
f(1, , 3)), but it would essentially allow `undefined` arguments to be
ommitted, if that would be considered useful.
[1] http://wiki.ecmascript.org/doku.php?id=harmony:spread
Thanks,
Sean Eagan
___
es
On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
Sorry to drag on about array holes, but:
Should holes in spread elements (e.g. [...holeyArray]) and arguments
(e.g. f(...holeyArray)) reflect as holes in the array
with |:
null | ##{...} // record-esque
null | ##[...] // tuple-esque
Include tuple-isms for #[], ##[]:
holes = syntax error
length cannot be greater than 2^32 - 1
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Sep 27, 2011 at 2:43 PM, Brendan Eich bren...@mozilla.com wrote:
On Sep 27, 2011, at 6:11 AM, Sean Eagan wrote:
On Mon, Sep 26, 2011 at 4:47 PM, Xavier MONTILLET
xavierm02@gmail.com wrote:
Normally, you use an object for optional arguments.
This is probably the most common case
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
(this).pairs;
pairs.delete(pair);
}
}
}
Are there other useful abstractions that could be built on top of
WeakPair, beyond WeakMap ?
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
productions. If we were to go that route, I would propose:
// replace | with prototypes
let B = A prototypes {
...
};
// replace with owns
let b = B owns {
...
};
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https
On Tue, Jul 19, 2011 at 9:39 AM, Sean Eagan seaneag...@gmail.com wrote:
// replace with owns
let b = B owns {
Sorry, that should have just been...
B owns {
...
}
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https
://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
let b = B + {}; // adding pointed to properties.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
. Call the [[DefineOwnProperty]] internal method of O with arguments
name, desc, and true.
6. Return O.
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I like the FixedHandler approach, one remaining concern I have though
is that without something like Proxy.isProxy, object consumers will
need to unnecessarily wrap non-proxy objects in order to guarantee
invariant maintenance.
Cheers,
Sean Eagan
___
es
be provided:
constructor(... args) {
super(... args);
}
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
to a default
constructor not to be forwarded to the superclass constructor.
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, and they benefit from the full dynamic super semantics!
I'm sure there are still details to work out, but it seems quite
promising to me.
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
A couple corrections below:
On Thu, Jun 23, 2011 at 9:14 AM, Sean Eagan seaneag...@gmail.com wrote:
When a super delegate function is subsequently accessed from an
object, e.g. o.methodThatUsesSuper or
Object.getOwnPropertyDescriptor(o,
accessorWithGetterOrSetterThatUsesSuper), this resolves
may still require a
defineSuperProperty proxy trap, not sure.
Also, I wonder if there is a need for a Function.prototype.isSuper
similar to Function.prototype.isGenerator?
On Thu, Jun 23, 2011 at 10:51 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Jun 23, 2011, at 3:14 PM, Sean Eagan wrote
|this|.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
:
getterThatReturnsMethodThatUsesSuper})|.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https
On Wed, Jun 22, 2011 at 9:23 AM, Axel Rauschmayer a...@rauschma.de wrote:
From: Sean Eagan seaneag...@gmail.com
Date: June 22, 2011 15:48:18 GMT+02:00
There is no infinite recursion hazard in the semantics that Axel
suggested, and that I used in the gist I posted
(https://gist.github.com
On Wed, Jun 22, 2011 at 10:01 AM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 6:48 AM, Sean Eagan wrote:
I don't think we need any safety check when assigning a method or
accessor getter or setter that uses super to an object. The concept
of super seems to be a relative one
too much.
Its value is already resolved via prototype climbing, I don't see the
tremendous cost is simply making this value accessible within the
function activation which occurs as a result of the prototype
climbing.
/be
Cheers,
Sean Eagan
___
es
because |super| uses it's sibling
|this| as the |this| in methods and accessor getter and setter calls
that result from |super| property access.
If by self you mean the same thing as Axel's here, then I don't
think that is desireable as Brendan earlier pointed out.
Peter
Cheers,
Sean Eagan
is as well with the combination
of object literal super and Object.defineMethod.
Sorry for any earlier rehashing, I didn't realize we agreed on those points.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org
On Wed, Jun 22, 2011 at 2:11 PM, Brendan Eich bren...@mozilla.com wrote:
On Jun 22, 2011, at 11:01 AM, Sean Eagan wrote:
On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
dopazo.j...@gmail.com wrote:
Can the value of a dynamic super be unambiguously resolved with prototype
climbing
://mail.mozilla.org/listinfo/es-discuss
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
compensation code), I think.
David
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https
Sorry, I meant remove the configurability check of the
getOwnPropertyDescriptor and getPropertyDescriptor trap return
values, and add a check as to whether the defineProperty trap return
value is an object to fix the property to.
On Thu, Jun 16, 2011 at 8:12 AM, Sean Eagan seaneag...@gmail.com
to indicate that the object cannot be made
non-extensible / sealed / frozen.
On Thu, Jun 16, 2011 at 8:15 AM, Sean Eagan seaneag...@gmail.com wrote:
Sorry, I meant remove the configurability check of the
getOwnPropertyDescriptor and getPropertyDescriptor trap return
values, and add a check
.
Cheers,
Tom
2011/5/4 Sean Eagan seaneag...@gmail.com
What:
Honor attempts to make individual proxy properties non-configurable.
Why:
For consistency since attempts to make *all* of a proxy's properties
non-configurable are honored via the fix trap.
Example:
var x = Proxy.create
:
( FormalParameterListOpt )
FormalParameterList : ...
this InitialiserOpt
this InitialiserOpt , FormalParameterList
[1] http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
Thanks,
Sean Eagan
___
es-discuss mailing list
es
));
or possibly
higher(-@ fact (n) n=1?1:n*fact(n-1));
(in either case the 3 character arrow sequence would be one token)
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
://wiki.ecmascript.org/doku.php?id=harmony:proxies_semantics
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, May 31, 2011 at 12:04 PM, Sean Eagan seaneag...@gmail.com wrote:
1. If O does not have a [[Handler]] internal property return [false].
2. Let handler be the value of the [[Handler]] internal property of O.
3. Let trap be the result of calling the [[Get]] internal method of
handler
is true, and whose second
element is the result of calling the [[Call]] internal method of trap
providing handler as the this value and Arguments appended with O as
the arguments.
On Tue, May 31, 2011 at 12:08 PM, Sean Eagan seaneag...@gmail.com wrote:
On Tue, May 31, 2011 at 12:04 PM, Sean Eagan
to be single characters for each attribute, if you
use the full names you are hardly gaining enough conciseness to make
it worthwhile.
On Thu, May 26, 2011 at 6:24 PM, Sean Eagan seaneag...@gmail.com wrote:
On Thu, May 26, 2011 at 4:27 PM, Sean Eagan seaneag...@gmail.com wrote:
Something similar could
?
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, May 27, 2011 at 10:10 AM, Sean Eagan seaneag...@gmail.com wrote:
I think the separation between proxies and regular objects is too
much. I would prefer to think of proxies as just a special kind of
object. All objects could be thought of as having a handler (
[[Handler]] ), and proxy
if the implementation allows property access
watching, no such notifications would be sent for property access on
builtins that occur within the default trap's code.
On Fri, May 27, 2011 at 11:12 AM, Brendan Eich bren...@mozilla.com wrote:
On May 27, 2011, at 8:10 AM, Sean Eagan wrote:
I think the separation
On Fri, May 27, 2011 at 12:18 PM, Sean Eagan seaneag...@gmail.com wrote:
Thanks, I wasn't aware of that history.
I'm not suggesting that default handlers or traps even should exist
from an implementation perspective, just that they could be a nice
specification mechanism now that we have
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation regardless of whether or not they are a proxy. Within
each internal
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote:
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation
On Fri, May 27, 2011 at 1:05 PM, Sean Eagan seaneag...@gmail.com wrote:
On Fri, May 27, 2011 at 12:43 PM, Sean Eagan seaneag...@gmail.com wrote:
Of course you could go the other way, and remove the default trap
implementations. All objects could have the same internal method
implementation
, May 26, 2011 at 11:54 AM, Sean Eagan seaneag...@gmail.com wrote:
On Thu, May 26, 2011 at 1:43 PM, Mike Shaver mike.sha...@gmail.com wrote:
On Thu, May 26, 2011 at 11:37 AM, Sean Eagan seaneag...@gmail.com wrote:
// ! implies non-writable, ~ implies non-enumerable
// all assignment operators can
-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
es-discuss mailing list
.html
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, May 26, 2011 at 1:43 PM, Mike Shaver mike.sha...@gmail.com wrote:
On Thu, May 26, 2011 at 11:37 AM, Sean Eagan seaneag...@gmail.com wrote:
// ! implies non-writable, ~ implies non-enumerable
// all assignment operators can be used
! a.b += c
Legal parse today, though I'm not sure you
On Thu, May 26, 2011 at 1:54 PM, Sean Eagan seaneag...@gmail.com wrote:
PostfixExpression:
BasicLeftHandSideExpression
Sorry, I meant:
PostfixExpression :
BasicLeftHandSideExpression
BasicLeftHandSideExpression [no LineTerminator here] ++
BasicLeftHandSideExpression [no LineTerminator
: false};
var x = nonExtensibleP @ {
x: x
}
Something similar could work for properties, need to think about it.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, May 26, 2011 at 4:27 PM, Sean Eagan seaneag...@gmail.com wrote:
Something similar could work for properties, need to think about it.
Here's a start:
// reusable descriptor
var allFalse = {configurable: false, writable: false, enumerable: false};
var foo = {
{configurable: false
=harmony:destructuring
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, May 24, 2011 at 9:02 AM, Sean Eagan seaneag...@gmail.com wrote:
// -
function A (){
var a = arguments[0];
Object.defineProperty(this, b, {configurable: false, enumerable:
false, writable: true, arguments[1]})
Object.defineProperty(this, c, {configurable: true, enumerable:
true
On Tue, May 24, 2011 at 9:10 AM, Brendan Eich bren...@mozilla.com wrote:
On May 24, 2011, at 7:02 AM, Sean Eagan wrote:
This conflicts with the existing:
var foo = bar;
{foo} // bar
{!foo} // false
No, just because |{!b}| is current syntax, doesn't mean that |var a = {!b}|
is.
I've
.
-Message d'origine- From: Sean Eagan
Sent: Saturday, May 21, 2011 10:10 AM
To: es-discuss
Subject: Proposal: Concise instance initialisation
Summary:
Update Object Literal Extensions [1] to integrate with constructor
parameters for concise instance initialization.
Details
,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, Sean Eagan wrote:
The basic idea is to integrate concise object literal extensions [1]
into classes with trait composition [2]. Here's an initial attempt at
the resulting syntax:
I've update [1] and integrated with some related proposals to make the
integrated proposal tree starting
=strawman:concise_object_literal_extensions
[2]
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
to a
falsey defineProperty trap invocation return value.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
consumers.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
...
// non-writable, but set trap still called
x.foo = baz;
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
...
Proxy.isProxy = function(objectOrProxy) {
let unlikelyPropertyName = _@_*__%_+_!_;
Object.defineProperty(objectOrProxy, unlikelyPropertyName, {});
return Object.getOwnPropertyDescriptor(objectOrProxy,
unlikelyPropertyName).configurable;
}
Thanks,
Sean Eagan
,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
8.12.5 step 4 also calls [[GetProperty]] on the receiver,
causing a [[GetProperty]] (not [[Put]]) call to propogate up the
prototype chain, meaning the proxy's getPropertyDescriptor (not
set) trap is called.
Thanks,
Sean Eagan
___
es-discuss mailing list
es
in a prototype chain, its set trap
should not be called, but again its getPropertyDescriptor trap.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This can also be seen by realizing that if proxyA's handler uses the
default get and set trap implementations, and proxyB is proxyA's
[[Prototype]], then proxyB's get and set traps will not be called
due to property access on proxyA, but rather its
getPropertyDescriptor trap.
Thanks,
Sean Eagan
Sorry, ignore the first paragraph in my last post, I included it at
the end instead. Thanks.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
or ES5 section 8.12.5 step 5.b for a setter. The
proxy's get / set trap would not get called, and thus would not
need the receiver arguments.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
handler = new Proxy.ForwardingHandler;
// customize |handler| as desired here
return new (Proxy.Constructor(handler))(...createArgs);
})();
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es
Proxy.Handler,
handler-per-instance use cases could be accommodated simply by
wrapping a singleton pattern around a handler.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
prematurely before state is initialized.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
of the issues I've seen mentioned. There is a
precedent for this in that a constructor's prototype property is
cached in the internal [[Prototype]] property of objects it constructs
during the call to [[Construct]].
[1] http://wiki.ecmascript.org/doku.php?id=strawman:uniform_proxies
Thanks,
Sean Eagan
ForwardingProxy = Proxy.Constructor(Proxy.Handler);
let proxy = new ForwardingProxy(target);
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
has an example of it, but it's not fully specified), then you could
just do this...
function ({a, b}){}
//or
function ({a: b, c: d}){}
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values
[3] http://wiki.ecmascript.org/doku.php?id=harmony:rest_parameters
[4] http://wiki.ecmascript.org/doku.php?id=strawman:shorter_function_syntax
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss
= (__ThisBindingIsExplicit__ ?
__ThisBinding__ : defaultThis), + __parameterList__] =
__arguments__; //...
);
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
+ ] = __arguments__; //...
);
I'll be quiet now.
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
stretching too much...
let Pizza = function(...toppings = [pepperoni]) {
this.toppings = toppings;
}
let pepperoni = new Pizza(), hawaiin = new Pizza(pineapple, ham);
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https
/013528.html
Cheers,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
, ...variableLength, last] = arr;
[interesting, ...notInteresting, alsoInteresting] = arr;
[interesting, ..., alsoInteresting] = arr;
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Whoops, first code block should have been...
let restDefaults = [2, 3];
let f = function(first, ...rest = restDefaults){}
f(1) // first - 1, rest - restDefaults
f(1, 2) // first - 1, rest - [2]
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss
?
Thanks,
Sean Eagan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
97 matches
Mail list logo
