Set and Map additions in the latest draft
On Monday, October 29, 2012 at 12:35 PM, Erik Arvidsson wrote:
Set.prototype.forEach
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: ecmascript#591
On Mon, Oct 29, 2012 at 9:35 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
Set.prototype.forEach
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.
Map.prototype.size and Set.prototype.size
These should presumably be enumerable?
Hmmm. Another interesting factor in deciding between method and accessor properties. FWIW, array.length is not enumerable.
On Oct 29, 2012, at 9:35 AM, Erik Arvidsson wrote:
Map.prototype.size and Set.prototype.size
These should presumably be enumerable?
Why? the most similar strings in the current spec. (Array.prototype.length, String.prototype.length) are not enumerable.
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: ecmascript#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?
Claus
Claus Reinke wrote:
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:
ecmascript#591Isn't an adapter supporting the use case as simple as:
(v,s) => f(v,v,s) ?
Not if everyone has to write that and wrap it around an otherwise-reusable f when sharing f among maps, weakmaps and sets.
More generally, is it really a good idea to treat Sets as "Arrays without duplicate elements"?
That's not the treatment here. The treatment is uniform signature for a shared forEach callback.
With object model reformation, one could even make set[v] evaluate to set.has(v).
+1 for reusable callbacks, these make a lot of sense even if not always used out there from lazy devs
said that, what is the status of size ? it was in then I have removed it from es6-collections fast polyfill now is back again ?
Moreover, will be size, for common naming convention purpose, be used also for string pointValues so that length will be the current misleading one but size will be the right amount of points per string ?
damn it now I am off topic ..
Not sure what you mean -- size is "in" as a getter (non-enumerable, I trust).
Andrea Giammarchi wrote:
Moreover, will be size, for common naming convention purpose, be used also for string pointValues so that length will be the current misleading one but size will be the right amount of points per string ?
Who ever said size would be provided for strings? Or that it is an apt name?
cool, I have asked 'cause only FF was exposing it and at some point I thought it was removed.
On Mon, Oct 29, 2012 at 6:47 PM, Brendan Eich <brendan at mozilla.org> wrote:
Not sure what you mean -- size is "in" as a getter (non-enumerable, I trust).
nobody, but I believe first String.prototype hack will be to put a "points" getter ( or "size", why not ) in order to retrieve the length in points rather than chars. size() is quite common, hence the question.
Set.prototype.forEach
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.
Map.prototype.size and Set.prototype.size
These should presumably be enumerable?