On Feb 14, 2013, at 8:47 AM, Nathan Wall wrote:
Hey Allen, thanks for clarifying.
What will happen to other Array methods which currently return Arrays?
`filter` is the primary one that comes to mind. Will `uint32array.filter((v)
= v != 0)` return a Uint32Array? (I think it should behave
will happen with the return values of `slice`, `splice`, and
`reverse`?.. not to mention `concat`, which I know is a much more complex beast.
Nathan
Subject: Re: Array subclassing, .map and iterables (Re: Jan 30 TC39 Meeting
Notes)
From: al...@wirfs
On 14 February 2013 02:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
As we discussed at the meeting, to rationally place Typed Arrays into the
same class hierarchy as Array would require refactoring Array.prototype into
multiple abstract superclasses. This seems like too large of a
Nathan Wall wrote:
Hey Allen, thanks for clarifying.
What will happen to other Array methods which currently return
Arrays? `filter` is the primary one that comes to mind. Will
`uint32array.filter((v) = v != 0)` return a Uint32Array? (I think
it should behave the same way `map` does.)
I
Andreas Rossberg wrote:
I'd say that either we properly clean up the Array hierarchy, or we
leave it alone. A half-baked solution that only applies to typed
arrays, and divorces them from the Array hierarchy, seems less
attractive than just doing the naive thing, i.e., TypedArray Array.
Agree
On Feb 11, 2013, at 7:13 PM, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you don't
mind, I have some questions/concerns I'd like to clear up. (In particular I
want to make sure I understand; I don't intend to argue for one side or the
other ATM, but
On Feb 12, 2013, at 4:54 AM, Aymeric Vitte wrote:
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
All the presentation decks from the meeting are publicly available at
http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013
the short form:
In ES5, today you can use
Rick Waldron wrote:
On Monday, February 11, 2013, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you
don't mind, I have some questions/concerns I'd like to clear up.
(In particular I want to make sure I understand; I don't intend to
argue
Le 10/02/2013 19:05, Allen Wirfs-Brock a écrit :
All the presentation decks from the meeting are publicly available at
http://wiki.ecmascript.org/doku.php?id=meetings:meeting_jan_29_2013
the short form:
In ES5, today you can use Array.prototype as the [[Prototype]] of
non-Array objects or
[to limit the length of my reply, I had to avoid responding to every
detail, trying to answer the gist of your message instead; please let
me know if I missed anything important]
Of course, you might argue that I could just call it like:
NodeList.from( [ div, span, p ].map(nodeName =
Allen Wirfs-Brock wrote:
On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:
But I still think it is simpler to specify .map returning array,
always. You know you get an Array, you don't have to worry about magic
of Set, Map etc., if you wish to have it in other kind of container,
use
On Feb 10, 2013, at 1:04 PM, Tab Atkins Jr. wrote:
From what I've seen in the examples in this topic so far, it looks
like Array#from takes a second optional argument, which is a function
that you map the iterable elements through first, before giving them
to the constructor. So, you would
Thank you for this explanation. This is very interesting! If you don't mind,
I have some questions/concerns I'd like to clear up. (In particular I want to
make sure I understand; I don't intend to argue for one side or the other ATM,
but this change may require me to refactor some old code
On Monday, February 11, 2013, Nathan Wall wrote:
Thank you for this explanation. This is very interesting! If you don't
mind, I have some questions/concerns I'd like to clear up. (In particular
I want to make sure I understand; I don't intend to argue for one side or
the other ATM, but
Thanks for the explanations and additional details. Let me first try
to rephrase, to see whether I've understood your reasoning:
The problem comes from the partial integration of types in ES,
specifically having typed arrays but no easy way to express and
control the types of the functions
Allen Wirfs-Brock wrote:
On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
ethods.
The choice we agreed to, at the meeting is
1) Array.prototype.map produces the same kind of array that it
was applied to, so:
for the above example m instance of V will be true.
On Sun, Feb 10, 2013 at 4:33 AM, Claus Reinke claus.rei...@talk21.comwrote:
(snip)
How would use produce an Array of strings from an Int32Array?
Somewhat like
Array.from( int32Array ).map( (elem) = elem.toString() )
Implementations would be free to replace the syntactic pattern
On Feb 10, 2013, at 1:33 AM, Claus Reinke wrote:
Thanks for the explanations and additional details. Let me first try to
rephrase, to see whether I've understood your reasoning:
The problem comes from the partial integration of types in ES, specifically
having typed arrays but no easy
On Feb 10, 2013, at 3:40 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
...
I think the best would be (it is dead simple): - to _always_ use
Array in map result
In your previous post you said:
1. .map should work for Array
On Sun, Feb 10, 2013 at 3:04 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Feb 10, 2013 at 11:18 AM, Rick Waldron waldron.r...@gmail.com
wrote:
(Assuming a future where the DOM's NodeList inherits from Array)
How would you produce a NodeList from an arbitrary array of strings?
One of the problems with map is that the return type of the function
might be different. With some pseudo syntax for types
function f(x : T) : V { ... }
var a : Array.T = ...
var b = a.map(f);
b is actually of type Array.V and not of Array.T
This becomes an issue with typed arrays at least.
On
On Feb 9, 2013, at 2:16 AM, Claus Reinke wrote:
I am trying to understand the discussion and resolution of
'The Array Subclassing Kind Issue'. The issue (though not its
solution) seemed simple enough
class V extends Array { ... }
m = (new V()).map(val = val);
console.log( m
Allen Wirfs-Brock wrote:
On Feb 9, 2013, at 2:16 AM, Claus Reinke wrote:
I am trying to understand the discussion and resolution of 'The
Array Subclassing Kind Issue'. The issue (though not its
solution) seemed simple enough
class V extends Array { ... } m = (new V()).map(val = val);
On Feb 9, 2013, at 3:01 PM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
ethods.
The choice we agreed to, at the meeting is
1) Array.prototype.map produces the same kind of array that it was
applied to, so:
for the above example m instance of V will be true.
24 matches
Mail list logo
