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
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
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
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,
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
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 in
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
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
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
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
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.
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,
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)
The more I think about it, I still can't come up with any really exciting use
casesnbsp;wherenbsp;Array.ofnbsp;would outshine anything that already
exists. I say strike it from the wishlist.
Array.from() still rules.
Rick
-- Sent from my Palm Pre
On Jul 10, 2011 12:59 PM, Dmitry A.
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
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 (and
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 that
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 that
And I don't see it still. Maybe you can explain it in some detail then
if you have understood it?
Dmitry.
On 10.07.2011 21:33, Rick Waldron wrote:
_that_ is the compelling use-case I was looking for.
Rick
-- Sent from my Palm Pre
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
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 ;)
-
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
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
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
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, 3, 2, 5]
Dmitry.
On 10.07.2011 23:02, Dmitry A. Soshnikov
On 10.07.2011 23:09, 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, 3, 2, 5]
On 10.07.2011 23:25, Juan Ignacio Dopazo wrote:
On Sun, Jul 10, 2011 at 2:35 PM, Dmitry A. Soshnikov
dmitry.soshni...@gmail.com mailto:dmitry.soshni...@gmail.com wrote:
On 10.07.2011 21:32, Allen Wirfs-Brock wrote:
On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote:
On Jul 10,
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 to
On Jul 10, 2011, at 12:02 PM, 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
On 11.07.2011 0:35, Brendan Eich wrote:
On Jul 10, 2011, at 12:02 PM, 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
30 matches
Mail list logo
