On Fri, Oct 10, 2014 at 4:12 PM, Rick Waldron <waldron.r...@gmail.com>
wrote:
>
>
> On Friday, October 10, 2014, Dmitry Soshnikov <dmitry.soshni...@gmail.com>
> 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
>
>
Don't think I can agree with this. An abstraction should be intuitive and
predictable. For arrays and maps a "key" makes sense, for sets -- does not.
And refactoring hazards are secondary in this sense (though, can be
considered I agree).
Dmitry
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
