Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)
claus.reinke at talk21.com
Wed Feb 20 09:58:12 PST 2013
>> I'd be interested to see your alternative design suggestion
>> (or, in fact, any more general approach to the issue at hand
>> that would fit into ES).
> From ES4, http://wiki.ecmascript.org/doku.php?id=proposals:static_generics.
Thanks for the pointer. However, I'd like to have even more generic
methods - e.g., map is useful for structures that do not have .length
or indexed elements.
To give you an idea of the possibilities I've got in mind, I've sketched
an overly simplistic system where classes can implement interfaces,
generic methods can be written over these implementations, and
generic code can be written using only the generic methods. The
code is available as
(you can run the "html" in a browser or with nodejs)
It does implement map for Array, String and Int32Array (also for
makePromise, if you're running this in nodejs, with q installed),
without extending the classes or their objects (no mixins, and
the generic map is class-independent and extensible).
To understand why this is simplistic, think about the copy&modify
involved with doing this for all typed array variations - that is
where class-level constructors and de-structurable classes would
come in handy, so that one could separately reuse the array-
and element-type-specific interface implementations (*).
(*) for those who do not switch off when they hear the word
'types' - even without a static type system, many of the ideas
could be carried over from how Haskell implements type classes;
it'll just be a little less convenient, and a little more explicit code
to write; and it'll require some language design work to translate
ideas away from the static typing context, into EcmaScript concepts;
if you want to read Haskell papers for ES language design ideas,
here are the beginnings of a little dictionary:
for 'type', read 'class'
for 'type class', read 'interface'
for 'type class instance', read 'interface implementation'
With this translation and the paper I referred to earlier in this
thread, one notices that interfaces in Haskell tend to relate
multiple classes, and that interface-implementing classes can
often be de-structured (e.g., Array<Int32> instead of Int32Array),
to facilitate access to the interfaces implemented by the class
components - that avoids a lot of duplicated code;
More information about the es-discuss