Re: Array.of

2014-03-03 Thread Brendan Eich
one would choose to use Array.of instead of the literal array syntax? Back when Dave Herman and I first dreamed up Array.of, I wrote this up: https://gist.github.com/rwaldron/1074126#arrayof--variable-arity- Rick Here is one case where literal array syntax is not possible

Array.of

2014-03-02 Thread Mark Volkmann
What is an example of a use case where one would choose to use Array.of instead of the literal array syntax? -- R. Mark Volkmann Object Computing, Inc. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Array.of

2014-03-02 Thread Claude Pache
Le 3 mars 2014 à 04:22, Mark Volkmann r.mark.volkm...@gmail.com a écrit : What is an example of a use case where one would choose to use Array.of instead of the literal array syntax? Here is one case where literal array syntax is not possible: class ImprovedArray extends Array

Re: About Array.of()

2013-12-18 Thread Shijun He
This is an old thread which I like to mention again. The proposal is change the method name from Array.of() to Array.fromElements() to make it clear especially for non-English native programmers. It seems the thread is totally ignored... On Tue, Aug 28, 2012 at 5:56 PM, Jussi Kalliokoski

Re: About Array.of()

2013-12-18 Thread Benjamin (Inglor) Gruenbaum
From: Shijun He hax@gmail.com Subject: Re: About Array.of() This is an old thread which I like to mention again. The proposal is change the method name from Array.of() to Array.fromElements() to make it clear especially for non-English native programmers. `Array.of` sounds a lot more

Re: About Array.of()

2013-12-18 Thread Benjamin (Inglor) Gruenbaum
Array.of sounds expressive only for native speakers. English is not my first language and it sounded expressive to me. I've asked 5 random friends that code and they all said it sounded fine to them. While that's not real evidence, it still shows that the only doesn't hold here. The only valid

Re: About Array.of()

2013-12-18 Thread Allen Wirfs-Brock
On Dec 18, 2013, at 11:01 AM, Shijun He wrote: ... 2) In fact such expressive is MEANINGLESS because we will never write `var a = Array.of(1, 2, 3)` instead of `var a = [1, 2, 3]` Note that 'of' works to create instances of subclasses or Array (and typed arrays) while array literals

Re: About Array.of()

2013-12-18 Thread Shijun He
On Thu, Dec 19, 2013 at 4:04 AM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: Array.of sounds expressive only for native speakers. English is not my first language and it sounded expressive to me. I've asked 5 random friends that code and they all said it sounded fine to them. While

Re: About Array.of()

2013-12-18 Thread Shijun He
On Thu, Dec 19, 2013 at 4:37 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: On Dec 18, 2013, at 11:01 AM, Shijun He wrote: ... 2) In fact such expressive is MEANINGLESS because we will never write `var a = Array.of(1, 2, 3)` instead of `var a = [1, 2, 3]` Note that 'of' works

Re: About Array.of()

2013-12-18 Thread Claude Pache
Array.from(arguments) } Remarkably, `Array.fromElements` sounds particularly bad to my ears, because it seems to be a synonym of `Array.from` when applied to an array. (Array from [the] elements [of] ...) Personally, I'd not thought that `Array.of` would be a problem, but apparently, since even people

Re: About Array.of()

2012-08-28 Thread Mikael Lindsten
My first post to this mailing list, so hi everyone! I agree with Domenic, Array.fromElements would be a good name (though I have no problem with Array.of). Just don't go with Array.new (I agree with Rick here, it should match the constructor - Array should be no exception, broken constructor

Re: About Array.of()

2012-08-28 Thread Maciej Stachowiak
On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name

Re: About Array.of()

2012-08-28 Thread Jussi Kalliokoski
On Tue, Aug 28, 2012 at 9:59 AM, Maciej Stachowiak m...@apple.com wrote: On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new

Re: About Array.of()

2012-08-28 Thread Axel Rauschmayer
However, I'm still not quite sure what the use case is for this. For code generation, if you know how many elements there are and what they are enough to put them in the Array.of(...,...,...) call, why not just use [...,...,...]? Unless it's supposed to be used for converting array-likes

Re: About Array.of()

2012-08-28 Thread Jussi Kalliokoski
On Tue, Aug 28, 2012 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote: However, I'm still not quite sure what the use case is for this. For code generation, if you know how many elements there are and what they are enough to put them in the Array.of(...,...,...) call, why not just use

Re: About Array.of()

2012-08-27 Thread Rick Waldron
I don't think that screenshots of search suggestions for a language feature that hasn't even been published is valid argument in this discussion. I'd also argue that these results support the current Array.of definition, eg. I need to make an array of strings: Array.of( A, B, C, D ); ...Which

Re: About Array.of()

2012-08-27 Thread Brendan Eich
Robb wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.com mailto:waldron.r...@gmail.com wrote: On Sunday

Re: About Array.of()

2012-08-27 Thread Kevin Smith
Isn't there a name that we already use for alternative constructors: create? let object = Object.create(null); let array = Array.create(A, B, C); Kevin ___ es-discuss mailing list es-discuss@mozilla.org

Re: About Array.of()

2012-08-27 Thread Brendan Eich
, with the wrong defaults for writable configurable and arguably enumerable. The Ruby precedent for Array.new appeals to me (and I'm not a Rubyist). I could live with Array.of but even ignoring search-engine usability, using a preposition for a constructor name, rather than a verb or a verb'ed

Re: About Array.of()

2012-08-27 Thread Rick Waldron
, which takes a pdmap as second parameter. That is a complicated beast, with the wrong defaults for writable configurable and arguably enumerable. The Ruby precedent for Array.new appeals to me (and I'm not a Rubyist). I could live with Array.of but even ignoring search-engine usability

Re: About Array.of()

2012-08-27 Thread Shijun He
On Tue, Aug 28, 2012 at 1:55 AM, Rick Waldron waldron.r...@gmail.com wrote: I don't think that screenshots of search suggestions for a language feature that hasn't even been published is valid argument in this discussion. I'd also argue that these results support the current Array.of

Re: About Array.of()

2012-08-27 Thread Shijun He
agree you 'new' should match constructor, except Array. Array constructor is broken (that's why we need Array.of/new/create whatever) and NO ONE really use Array constructor at all (programmers are educated to use literal initializer instead). -- hax

Re: About Array.of()

2012-08-27 Thread Brendan Eich
do I wish to I agree you 'new' should match constructor, except Array. Array constructor is broken (that's why we need Array.of/new/create whatever) and NO ONE really use Array constructor at all (programmers are educated to use literal initializer instead). Too true. Rick, it's important

Re: About Array.of()

2012-08-27 Thread Rick Waldron
as its operator equivalent (for all constructors, not just Array). By no means do I wish to I agree you 'new' should match constructor, except Array. Array constructor is broken (that's why we need Array.of/new/create whatever) and NO ONE really use Array constructor at all (programmers

Re: About Array.of()

2012-08-27 Thread 程劭非
;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r

Re: About Array.of()

2012-08-27 Thread 程劭非
;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r

Re: About Array.of()

2012-08-27 Thread Domenic Denicola
: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.com wrote: On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich

About Array.of()

2012-08-26 Thread Shijun He
Hi, I don't think Array.of() is useful, just stick on array literal seems enough: var a = [1,2,3] var a1 = [3] Why we need this: var a = Array.of(1,2,3) var a1 = Array.of(3) Is there any special benefit I missed? And there is another reason why I don't like Array.of() , myself write a small

Re: About Array.of()

2012-08-26 Thread Rick Waldron
Thanks for the feedback, allow me to explain the rationale for Array.of: One of the main goals of ES6 is to become a better language for library writers and code generators. For compilation targets, ES/JS can't assume that implementations will always know what its factories are expected

Re: About Array.of()

2012-08-26 Thread Brendan Eich
Rick Waldron wrote: If you replace that by using Array.of(), you avoid this gotcha That's right -- Array.of is an alternative constructor to use in preference to Array, on account of Array's heinous special-case for the one-numeric-argument case

Re: About Array.of()

2012-08-26 Thread Shijun He
, ...rest ) { return new construct( rest ); })( Array, 10 ); The result of `o` will be an array with 10 empty indexes, as if it were called like: new Array(10) If you replace that by using Array.of(), you avoid this gotcha So you still need some code like: if (constructor === Array

Re: About Array.of()

2012-08-26 Thread Brendan Eich
Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name. It's darn nice for Rubyists. OTOH Array.of matches the preposition

Re: About Array.of()

2012-08-26 Thread Rick Waldron
On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property

Re: About Array.of()

2012-08-26 Thread Matthew Robb
I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.comwrote: On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich wrote

Re: About Array.of()

2012-08-26 Thread Matthew Robb
of array of in non-english languages seems most come from the programmers' input, so it shows how worldwide programmers think what array of means ;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing

Re: Pure win: Array.from and Array.of

2011-07-30 Thread Andrea Giammarchi
Alex I think whatever method we have natively won't be enough for this or that case, plus once a method is implemented native his signature becomes legacy developers may like or not. With Object.defineProperty we *could* pollute Array.prototype avoiding the most annoying and idiotic thing

Re: Pure win: Array.from and Array.of

2011-07-26 Thread Andrea Giammarchi
glad somebody said that! Also I would pollute performance oriented methods rather than whatever framework sugar anybody could easily add where unique() and remove(all) may be part of these cases while fill() could be superfluous. Andrea On Mon, Jul 11, 2011 at 6:01 PM, Allen Wirfs-Brock

Re: Pure win: Array.from and Array.of

2011-07-26 Thread Alex Russell
On Jul 26, 2011, at 7:10 AM, Andrea Giammarchi wrote: glad somebody said that! Also I would pollute performance oriented methods rather than whatever framework sugar anybody could easily add where unique() and remove(all) may be part of these cases while fill() could be superfluous. I feel

Re: Pure win: Array.from and Array.of

2011-07-11 Thread Allen Wirfs-Brock
On Jul 10, 2011, at 12:09 PM, Dmitry A. Soshnikov wrote: And by the way, an efficient `Array.prototype.unique` also would be nice to have, since in JS in general it's hard to implement it's efficiently (in lower level at least it will iterate faster). [1, 3, 2, 5, 5, 3].unique(); // [1,

Re: Pure win: Array.from and Array.of

2011-07-11 Thread Dmitry A. Soshnikov
On 11.07.2011 20:01, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 12:09 PM, Dmitry A. Soshnikov wrote: And by the way, an efficient `Array.prototype.unique` also would be nice to have, since in JS in general it's hard to implement it's efficiently (in lower level at least it will iterate

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
Array.from is a good addition, I guess any good framework has it. Though, `Array.of` in contrast doesn't bring much of a sugar. Compare these two apples-to-apples: Array.of( things, that, aren't, currently, an, array ) vs. [things, that, aren't, currently, an, array] what's the goal

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 14:27, Mike Shaver wrote: On Sun, Jul 10, 2011 at 6:06 AM, Dmitry A. Soshnikov dmitry.soshni...@gmail.com wrote: The problem: Array(4).map(function(x) x * x); // [NaN, NaN, NaN, NaN] I think it actually produces just [ , , , , ], because map skips holes. (If you see the NaN

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Mike Shaver
On Sun, Jul 10, 2011 at 7:09 AM, Dmitry A. Soshnikov dmitry.soshni...@gmail.com wrote: If I hadn't made map skip holes, then the fill pattern would be simple enough: Array(4).map(function (_,x) x * x); It's in particular case, you try to multiply indices, which in current implementation of

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 15:14, Mike Shaver wrote: On Sun, Jul 10, 2011 at 7:09 AM, Dmitry A. Soshnikov dmitry.soshni...@gmail.com wrote: If I hadn't made map skip holes, then the fill pattern would be simple enough: Array(4).map(function (_,x) x * x); It's in particular case, you try to multiply

Array generation (was: Pure win: Array.from and Array.of)

2011-07-10 Thread David Bruant
Le 10/07/2011 12:06, Dmitry A. Soshnikov a écrit : (...) Another thing to consider is `Array.prototype.fill` method which we discussed before. The problem: Array(4).map(function(x) x * x); // [NaN, NaN, NaN, NaN] (by the way, this mistaken example is still mentioned in this document

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
On Jul 10, 2011, at 3:06 AM, Dmitry A. Soshnikov wrote: Array.from is a good addition, I guess any good framework has it. Though, `Array.of` in contrast doesn't bring much of a sugar. Compare these two apples-to-apples: Array.of( things, that, aren't, currently, an, array ) vs

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 20:36, Brendan Eich wrote: On Jul 10, 2011, at 3:06 AM, Dmitry A. Soshnikov wrote: Array.from is a good addition, I guess any good framework has it. Though, `Array.of` in contrast doesn't bring much of a sugar. Compare these two apples-to-apples: Array.of( things, that, aren't

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
On Jul 10, 2011, at 9:59 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 20:36, Brendan Eich wrote: So the goal of Array.of is to provide a constructor that, unlike Array, does not have that insane special case for Array(42), which presets length (and hints to implementations to preallocate

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Rick Waldron
A. Soshnikov lt;dmitry.soshni...@gmail.comgt; wrote: On 10.07.2011 20:36, Brendan Eich wrote: gt; On Jul 10, 2011, at 3:06 AM, Dmitry A. Soshnikov wrote: gt; gt;gt; Array.from is a good addition, I guess any good framework has it. gt;gt; gt;gt; Though, `Array.of` in contrast doesn't bring much

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of would outshine anything that already exists. I say strike it from the wishlist. Higher-order programming with Array as constructing-function

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 21:18, Brendan Eich wrote: On Jul 10, 2011, at 9:59 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 20:36, Brendan Eich wrote: So the goal of Array.of is to provide a constructor that, unlike Array, does not have that insane special case for Array(42), which presets length

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 21:32, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of http://Array.of/ would outshine anything

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
On Jul 10, 2011, at 10:32 AM, Allen Wirfs-Brock wrote: On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of would outshine anything

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On Jul 10, 2011 1:23 PM, Brendan Eich bren...@mozilla.com wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of http://Array.of/ would outshine anything that already exists. I say

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Allen Wirfs-Brock
On Jul 10, 2011, at 10:32 AM, Allen Wirfs-Brock wrote: Yes, if you actually need to pass Array.of as a function argument. Of course if we have block lambdas you could just say: hof({|a|[a]}) instead of hof(Array.of) actually the above aren't equivalent. The block lambda

Re: Pure win: Array.from and Array.of

2011-07-10 Thread John-David Dalton
I dig Array.from, and have manually made sugar for that in my projects. Array.of is something I have also wanted though I had been struggling with a name for it. Until now if I wanted to avoid setting the array length I would do something like ns.Array.from([23]), but Array.of is nice too

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 22:26, John-David Dalton wrote: I dig Array.from, and have manually made sugar for that in my projects. Array.of is something I have also wanted though I had been struggling with a name for it. It's interesting -- can you show where and how? Until now if I wanted to avoid

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
On Jul 10, 2011, at 10:40 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of would outshine anything that already

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
On 10.07.2011 22:44, Brendan Eich wrote: On Jul 10, 2011, at 10:40 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
wrote: On 10.07.2011 22:44, Brendan Eich wrote: On Jul 10, 2011, at 10:40 AM, Dmitry A. Soshnikov wrote: On 10.07.2011 21:23, Brendan Eich wrote: On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
with any really exciting use cases where Array.of http://Array.of/ would outshine anything that already exists. I say strike it from the wishlist. Higher-order programming with Array as constructing-function bites back for the single-number-argument case. That's where Array.of helps. You mean

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
, 2011, at 10:18 AM, Rick Waldron wrote: The more I think about it, I still can't come up with any really exciting use cases where Array.of http://Array.of/ would outshine anything that already exists. I say strike it from the wishlist. Higher-order programming with Array

Re: Pure win: Array.from and Array.of

2011-07-10 Thread David Herman
I mentioned two benefits I can see to Array.of over []-literals here: https://twitter.com/#!/littlecalculist/status/89854372405723136 1) With Array.of you know you aren't going to accidentally create holes, and 2) if you're passing it to a higher-order function you know you aren't going

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Brendan Eich
can't come up with any really exciting use cases where Array.of would outshine anything that already exists. I say strike it from the wishlist. Higher-order programming with Array as constructing-function bites back for the single-number-argument case. That's where Array.of helps. You

Re: Pure win: Array.from and Array.of

2011-07-10 Thread Dmitry A. Soshnikov
: The more I think about it, I still can't come up with any really exciting use cases where Array.of http://Array.of/ would outshine anything that already exists. I say strike it from the wishlist. Higher-order programming with Array as constructing-function bites back for the single-number