Array subclassing, .map and iterables (Re: Jan 30 TC39 MeetingNotes)

[Claus Reinke]

>> 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 

    https://gist.github.com/clausreinke/4997274

(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 (*).

Claus

(*) 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;