Set and Map additions in the latest draft
claus.reinke at talk21.com
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
> Yes, I've reopened the bug for this: https://bugs.ecmascript.org/show_bug.cgi?id=591
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