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 15:54, David Bruant wrote:
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
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 9, 2011, at 7:22 PM, Brendan Eich wrote:
On Jul 9, 2011, at 5:02 PM, Allen Wirfs-Brock wrote:
...
1) stratification - Proxy.isProxy is an example
2) It is impossible or inconvenient to add the classification interface to
the appropriate instance interface. I think that was the
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
Hi Dave:
According to the module grammar, the following is valid:
691module car {
function startCar() {} module engine { function start() {} } export
{start:startCar} from engine;
}
It seems like there would be issues with exporting module elements after the
module has been defined.
Also,
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,
So from this viewpoint (and regarding that example with squares), it's good
to have also `Array.seq(from, to)` method (the name is taken from Erlang, I
just frequently uses lists:seq(from, to) there):
bikeshedArray.range seems like an intuitive name as well./bikeshed
Array.seq(1,
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
Here I put some extensions for arrays standard library (separated from
this thread:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html
where Array.of and Array.from were considered).
We can consider also the following (as a first step):
*- Array.prototype.remove(value, all)*
In addition, here's Erlang's one, which has rich lists library --
http://www.erlang.org/doc/man/lists.html Some/most methods are already
implemented in JS of course (though, by different names), but we can
take missing, but needed (and thus implemented in many JS libs) methods.
Dmitry.
On
David, I like the way you paint your bike sheds. Array.range() (or similarly
functional but differently named) is definitely another one of those
oft-rerolled solutions.
Rick
On Sun, Jul 10, 2011 at 4:23 PM, David Herman dher...@mozilla.com wrote:
So from this viewpoint (and regarding that
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically know how to produce a SubArray as its result if
that's
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two traversals that's in many Schemes is
map-filter or filter-map:
a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res
!== void 0)]
I rather arbitrarily chose to
Agreed. I think that's a pretty common way people think about null vs
undefined, and it's consistent with the language's behavior.
Dave
On Jul 10, 2011, at 3:09 PM, liorean wrote:
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two
Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit :
Here I put some extensions for arrays standard library (separated from
this thread:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html
where Array.of and Array.from were considered).
We can consider also the following (as a
As a sidenote, but with regard to forEach, can someone point me to some
documentation that explains why the generic form of forEach doesn't work with
objects (the use case has sufficient history)
Rick
-- Sent from my Palm Pre
On Jul 10, 2011 6:42 PM, David Bruant lt;david.bru...@labri.frgt;
On Jul 10, 2011, at 3:02 PM, David Herman wrote:
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want to work how. For
example, .map can't magically
On Jul 10, 2011, at 3:54 PM, Brendan Eich wrote:
On Jul 10, 2011, at 3:02 PM, David Herman wrote:
I'm not sure what Array.prototype methods would or wouldn't work on
instances of SubArray.
All of them. They are all generic.
We're speaking too broadly here. It depends on what we want
range.__doc__
'range([start,] stop[, step]) - range object\n\nReturns a virtual sequence of
numbers from start to stop by step.'
[i for i in range(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[i for i in range(10, 20)]
[10, 11, 12, 13, 14, 15, 16, 17, 18, 19]
[i for i in range(10, 20, 2)]
[10, 12, 14,
On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
However, arguably Array.isArray really should have been
Array.prototype.isArray. We treated as a case 2 from above. May we really
didn't need to, but that's water over dam. I don't think we should use it
as precedent for more
According to the module grammar, the following is valid:
691module car {
function startCar() {}
module engine {
function start() {}
}
export {start:startCar} from engine;
}
It seems like there would be issues with exporting module elements after the
module has been
42 matches
Mail list logo
