An old discussion. See: https://esdiscuss.org/topic/set-and-map-additions-in-the-latest-draft https://esdiscuss.org/notes/2012-07-26 (section heading: Map and Set methods: conclusion) https://bugs.ecmascript.org/show_bug.cgi?id=591
Allen On Oct 10, 2014, at 4:12 PM, Rick Waldron wrote: > > > On Friday, October 10, 2014, Dmitry Soshnikov <[email protected]> > wrote: > Hi, > > (sorry I again probably too late, if the API is already locked, very likely > it has been discussed and approved, please let me know) > > The API of `Set`s seems in inconvenient way exposes things that relates only > to implementation details, but which doesn't make big sense at abstraction > usage level. > > In particular, the `keys` and `entries` methods. I understand that `Set`s are > just backed by `Map`s, and for simplicity of the specification reuse the same > iteration algorithms (which by default calls `entries` for maps in `for-of`). > > But `keys` just doesn't make sense for sets, and the most inconvenient is > callback function for `forEach` (and later for `map` and `filter` when they > will be introduced). If devs want to analyze the set object itself, they have > to repeat twice the "value" in parameters. > > ``` > (new Set([1,2,3])).forEach((value, againValue, theSet) => { > // huh? againValue? > ... > }); > ``` > > The designed to match A.p.forEach parameters to reduce refactoring hazards. > > Rick > > > Are we OK with this? Seems like removing `entries`, `keys` and providing own > default `@@iterator` for `Set` which should be just `values()` would make it > more sense from the abstraction usage perspective. > > Dmitry > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
