On Nov 5, 2010, at 6:19 PM, Erik Arvidsson wrote:
> On Fri, Nov 5, 2010 at 17:46, Brendan Eich wrote:
>> You mean
>>
>> f(1, 2, ...(x || []))
>>
>> at least.
>
> No need for the parens here [*]. Do you want it for readability?
Maybe. Or a space. It's unusual to have a low precedence prefix o
On Fri, Nov 5, 2010 at 17:46, Brendan Eich wrote:
> You mean
>
> f(1, 2, ...(x || []))
>
> at least.
No need for the parens here [*]. Do you want it for readability?
[*] http://wiki.ecmascript.org/doku.php?id=harmony:spread#syntax
--
erik
___
es-dis
On Nov 5, 2010, at 5:32 PM, Jason Orendorff wrote:
> On Thu, Nov 4, 2010 at 8:07 PM, John Lenz wrote:
>> It would seem friendlier for the spread operator to treat it them as a empty
>> array otherwise you end up with code like:
>> if (x!=null) {
>> f(1,2,...x)
>> } else {
>> f(1,2)
>> }
>
>
On Thu, Nov 4, 2010 at 8:07 PM, John Lenz wrote:
> It would seem friendlier for the spread operator to treat it them as a empty
> array otherwise you end up with code like:
> if (x!=null) {
> f(1,2,...x)
> } else {
> f(1,2)
> }
I'm late to the party, but note that you could instead write
On Nov 5, 2010, at 10:30 AM, Jon Zeppieri wrote:
> But... I hadn't realized that the spread proposal already included
> array-likes. In that case, there is no symmetry to preserve. The (now badly
> misnamed) id function will produce an array from an array-like -- and from
> null or undefined, u
Thanks for all the feedback. I've updated
http://wiki.ecmascript.org/doku.php?id=harmony:spread to reflect this.
On Fri, Nov 5, 2010 at 10:30, Jon Zeppieri wrote:
>
>
> On Fri, Nov 5, 2010 at 11:16 AM, Mike Samuel wrote:
>>
>> 2010/11/5 Jon Zeppieri :
>> >
>> > To the extent that the spread oper
On Fri, Nov 5, 2010 at 11:16 AM, Mike Samuel wrote:
> 2010/11/5 Jon Zeppieri :
> >
> > To the extent that the spread operator and rest args should be
> symmetrical,
> > the following function should be an identity over its domain:
> > function id(x) {
> > return (function(...x) { return x; })(.
On Nov 5, 2010, at 8:32 AM, Dean Landolt wrote:
> Considering the primary use-case for spread is a sugaring for
> Function.prototype.apply I would expect the same semantics.
"Gimme some sugar, baby!" - Ash Williams
Everyone's into sugar. Good. (Eggs are next. "Eggs have gotten a bad rap,
Smith
On Fri, Nov 5, 2010 at 11:23 AM, Brendan Eich wrote:
> On Nov 5, 2010, at 7:56 AM, Jon Zeppieri wrote:
>
> > Second issue: Erik suggests (plan B) that null and undefined are
> specifically special cased. I can't tell whether Brendan agrees with that or
> wants spread to be legal on any input what
On Nov 5, 2010, at 7:56 AM, Jon Zeppieri wrote:
> Second issue: Erik suggests (plan B) that null and undefined are specifically
> special cased. I can't tell whether Brendan agrees with that or wants spread
> to be legal on any input whatsoever, because he writes that spread "should
> return an
2010/11/5 Jon Zeppieri :
>
>
> On Fri, Nov 5, 2010 at 8:14 AM, P T Withington wrote:
>>
>> [2p. from the Lisp world, the putative inventor of the rest/spread
>> operator.]
>>
>> In Lisp, arglists are lists instead of arrays, the operator is `.`, and
>> conveniently, the empty list, `()`, and Lisp
On Fri, Nov 5, 2010 at 8:14 AM, P T Withington wrote:
> [2p. from the Lisp world, the putative inventor of the rest/spread
> operator.]
>
> In Lisp, arglists are lists instead of arrays, the operator is `.`, and
> conveniently, the empty list, `()`, and Lisp null, `NIL`, are just two ways
> to wr
[2p. from the Lisp world, the putative inventor of the rest/spread operator.]
In Lisp, arglists are lists instead of arrays, the operator is `.`, and
conveniently, the empty list, `()`, and Lisp null, `NIL`, are just two ways to
write the same atom. In Lisp, option B just falls out:
(f . NIL
On Thu, Nov 4, 2010 at 10:34 PM, Jon Zeppieri wrote:
>
>
> On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri wrote:
>
>>
>>
>> On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich wrote:
>>
>>> On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
>>>
>>> It would seem friendlier for the spread operator to treat it
On Thu, Nov 4, 2010 at 10:48 PM, Jon Zeppieri wrote:
>
>
> Spread-as-rest-arg-syntax constructs an array. Spread-as-operator splices
> the elements of an array into an argument list.
>
> So, if a spread operator expression: ...null splices zero values into an
> argument list, then its counterpart
On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri wrote:
>
>
> On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich wrote:
>
>> On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
>>
>> It would seem friendlier for the spread operator to treat it them as a
>> empty array otherwise you end up with code like:
>>
>>
On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich wrote:
> On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
>
> It would seem friendlier for the spread operator to treat it them as a
> empty array otherwise you end up with code like:
>
> if (x!=null) {
> f(1,2,...x)
> } else {
> f(1,2)
> }
>
>
> Yeah
On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
> It would seem friendlier for the spread operator to treat it them as a empty
> array otherwise you end up with code like:
>
> if (x!=null) {
> f(1,2,...x)
> } else {
> f(1,2)
> }
Yeah, null testing is a drag. People skipt it (I hear this about
It would seem friendlier for the spread operator to treat it them as a empty
array otherwise you end up with code like:
if (x!=null) {
f(1,2,...x)
} else {
f(1,2)
}
On Thu, Nov 4, 2010 at 5:54 PM, Erik Arvidsson wrote:
> We've run into an edge case with the spread operator. What should
> h
We've run into an edge case with the spread operator. What should
happen if we try to spread null or undefined?
f(...undefined);
A. Throw an error
B. Follow the path of Function.prototype.apply and others and special
case null and undefined and just call f with 0 arguments
--
erik
_
20 matches
Mail list logo
