Set and Map additions in the latest draft

Claus Reinke claus.reinke at
Mon Oct 29 12:15:39 PDT 2012

>> I thought it was agreed that the function passed to
>> Set.prototype.forEach would be called with 3 arguments, the value, the
>> value again and the context object. This is so that one can use the
>> same function for Array.prototype.forEach, Map.prototype.forEach and
>> Set.prototype.forEach.
> Yes, I've reopened the bug for this:

Isn't an adapter supporting the use case as simple as:

    (v,s) => f(v,v,s) ?

More generally, is it really a good idea to treat Sets as 
"Arrays without duplicate elements"?

Supporting this idea constrains implementations (no small sets as 
bitmaps, one needs consistent iteration order, too). And with type
support making inroads in JS tools and implementations, what is 
this idea going to do to types?

    Array.forEach : ((Element, Number, Array[Element]) => void) => void
    Map.forEach : ((Element, Key, Map[Key,Element]) => void) => void
    Set.forEach : ((Element, ???, Set[Element]) => void) => void

Instead of fixing ??? to Element, which won't work if the Array
callback uses its index parameter, one might want to use a type
representing "don't use this", to avoid accidental late errors when
using Array callbacks in Set forEach. 

In languages with support for unevaluated parameters, one would 
pass in an expression that would throw an explicit error if evaluated.

Even with explicit adapters, one cannot always gloss over the 
differences, so what is the advantage of enshrining one fixed
implicit adapter in the API? 



More information about the es-discuss mailing list