On Nov 11, 2011, at 9:47 AM, Axel Rauschmayer wrote:
>> function createArraySubclass(proto,...values) {
>> return proto <| [...values].{
>> [Array.derivedArrayKey](){return proto<| [ ]}
>> }
>> }
>
> I’m curious: Why wouldn’t one extend Array, instead?
the problem is with built-ins like Array.prototype.filter that produce a new
collection object. Today the new collection is always an Array, but for some
operations you would really like the new collection to be the same kind of
collection as original collection or something other than Array.
In Smalltalk (and I believe self) this is done by collections having a methods
named "species" that returns the class that should be used to create the new
collection. Part of the design of a new collection class is the assignment of
its "species". In my sketch above, a call to the private derivedArray method
is the equivalent to saying:
self species new
in Smalltalk.
So, if I have an object created by creteArraySubclass and say:
let f = obj.filter(function(element) {return isGood(element)});
then f will be an instance of the array subclass rather than a direct instance
of Array.
This also would work if obj was any generic array-like collection that had a
derivedArray method. Even if the collection didn't inherit from Array.prototype
let f = [].filter.call(obj,function(element) {return isGood(element)});
If the built-in Array prototype functions were respecified to use
elementGet/elementSet from
http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation
instead of [[Get]]/[[DefineOwnProperty]] to process elements then those
functions would work with any collection that had integer indexed keyed data
elements.
Allen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
