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

[Claus Reinke]

>> More immediately relevant for this thread, I would like to see
>>
>>    Array < Container
>>
>> with map, from, filter, and perhaps some others, moving from
>> Array to Container. Then Map and Set would be Containers, 
>> supporting operations currently limited to Array 
> 
> This is not gonna happen for several reasons, one being backward 
> incompatibility.
> 
> It's also unnecessary. The generic methods could (and should, some 
> think -- I prototyped this years ago in SpiderMonkey) have their |this| 
> parameters uncurried and be provided as functions. That would be a 
> better route than OOP tyranny of hierarchy.

That particular suggestion was somewhat tongue-in-cheek, to get
the thread back to technical issues;-) - I don't want the operations 
limited to Array (and subclasses) but I also don't think that single-
inheritance prototype hierarchy is offering a good solution here. 

To begin with, the usefulness of map isn't limited to container-like 
classes, and map's implementation cannot always be inherited, so 
we're really talking about interfaces (or abstract classes).

And if existing code was written to interfaces, rather than taking
a specific prototype chain into account, backward incompatibility
would be less of a problem.

The whole thread is about using a specific and acute example 
decision (what to do with .map/.from) to trigger a discussion of 
the larger language design issues and options that would help 
addressing this kind of problem (which combines programming
to interfaces, generic methods outside the class hierarchy, and
selection of such methods based on the class of not-yet-existing
objects). Preferably before individual cases are fixed that might
not fit a later general solution pattern.

I mentioned type constructor classes not because of the type
system they are embedded in (or, rather, built over), but because 
they offer a logic and implementation pattern for dealing with 
interfaces and with generic code written to interfaces. 

The un-optimized implementation of generic code in that system
is to pass dictionaries of methods around, combining the method 
implementations in a way analogous to the way the types are
constructed. It is a systematic generalization of the target-class-
passing illustrated in Rick's code fragment earlier in this thread.

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

Claus