Set API

[Dmitry Soshnikov]

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?
...
});
```

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/84aa92dd/attachment.html>

[Domenic Denicola]

+1. When reading the draft and spontaneously discovering this wierdness I was extremely surprised.

That said, Set is shipping in every major browser so it's not going to get fixed now.
________________________________
From: Dmitry Soshnikov<mailto:dmitry.soshnikov at gmail.com>
Sent: ?2014-?10-?10 18:56
To: es-discuss<mailto:es-discuss at mozilla.org>
Subject: Set API

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?
...
});
```

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/718972dc/attachment.html>

[Brendan Eich]

Post by Domenic Denicola
That said, Set is shipping in every major browser so it's not going to get fixed now.

Why do you say that?

/be

[Dmitry Soshnikov]

Post by Brendan Eich

Post by Domenic Denicola
That said, Set is shipping in every major browser so it's not going to get fixed now.

Why do you say that?

Yeah, since the spec normally changes in some small parts, as e.g. with
recent change to `Array#last` and `Array#lastIndex` which do not skip holes
anymore (which is not the best from the compatibility with other similar
methods like `Array#map`, `Array#forEach`, etc). But as long as it's a new
policy, and why bother with holes if most of arrays are dense, not sparse
-- probably OK, I fixed my polyfills already. This is just for the word,
that browser change their implementations gradually anyway, once spec
changes.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/987418dc/attachment.html>

[Dmitry Soshnikov]

On Fri, Oct 10, 2014 at 4:13 PM, Dmitry Soshnikov <

Post by Dmitry Soshnikov

Post by Brendan Eich

Post by Domenic Denicola
That said, Set is shipping in every major browser so it's not going to get fixed now.

Why do you say that?

Yeah, since the spec normally changes in some small parts, as e.g. with
recent change to `Array#last` and `Array#lastIndex`

Err, sorry, `Array#find`, and `Array#findIndex` I meant of course (can't
edit posts).

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/0d7ac74e/attachment.html>

[Rick Waldron]

On Friday, October 10, 2014, Dmitry Soshnikov <dmitry.soshnikov at gmail.com>

On Fri, Oct 10, 2014 at 4:09 PM, Brendan Eich <brendan at mozilla.org

Post by Brendan Eich

Post by Domenic Denicola
That said, Set is shipping in every major browser so it's not going to get fixed now.

Why do you say that?

Yeah, since the spec normally changes in some small parts, as e.g. with
recent change to `Array#last` and `Array#lastIndex` which do not skip holes
anymore (which is not the best from the compatibility with other similar
methods like `Array#map`, `Array#forEach`, etc).

Clarifying: find and findIndex

But as long as it's a new policy, and why bother with holes if most of
arrays are dense, not sparse -- probably OK, I fixed my polyfills already.
This is just for the word, that browser change their implementations
gradually anyway, once spec changes.
Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/ad13b8e2/attachment.html>

[Domenic Denicola]

From: Brendan Eich [mailto:brendan at mozilla.org]

Post by Brendan Eich

Post by Domenic Denicola
That said, Set is shipping in every major browser so it's not going to get fixed now.

Why do you say that?

I would guess that, via the usual `if (!window.Set) { window.Set = ... }` polyfills , there is a nontrivial fraction of the web depending on the current behavior.

[Rick Waldron]

On Friday, October 10, 2014, Dmitry Soshnikov <dmitry.soshnikov at gmail.com

Post by Dmitry Soshnikov
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

Post by Dmitry Soshnikov
Are we OK with this? Seems like removing `entries`, `keys` and providing
make it more sense from the abstraction usage perspective.
Dmitry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/865f2e35/attachment.html>

[Dmitry Soshnikov]

On Fri, Oct 10, 2014 at 4:12 PM, Rick Waldron <waldron.rick at gmail.com>

On Friday, October 10, 2014, Dmitry Soshnikov <dmitry.soshnikov at gmail.com>

Post by Dmitry Soshnikov
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141010/f923d5fc/attachment-0001.html>

[Allen Wirfs-Brock]

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

Post by Domenic Denicola
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
Dmitry
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141013/8eff3757/attachment.html>

[Dmitry Soshnikov]

On Mon, Oct 13, 2014 at 8:43 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>

Post by Allen Wirfs-Brock
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

OK, thanks for the info Allen. I guess, as long as it really was designed
this way (for reusable callbacks at first place), it's probably fine.
Though I still can predict confusions there.

Dmitry

Post by Allen Wirfs-Brock
Allen

Post by Dmitry Soshnikov
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

Post by Dmitry Soshnikov
Are we OK with this? Seems like removing `entries`, `keys` and providing
make it more sense from the abstraction usage perspective.
Dmitry

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141013/9b2d0dbe/attachment.html>

[Domenic Denicola]

From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
These only address the `forEach` method though, and not the strange design of `entries()`, `values()`, and `keys()`. I guess a reusability argument could be made, but it seems strange to drive the API with the idea of wanting to reuse a Set in places people expect a Map.

[Dmitry Soshnikov]

On Mon, Oct 13, 2014 at 3:22 PM, Domenic Denicola <

Post by Domenic Denicola
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Allen Wirfs-Brock
These only address the `forEach` method though, and not the strange design
of `entries()`, `values()`, and `keys()`. I guess a reusability argument
could be made, but it seems strange to drive the API with the idea of
wanting to reuse a Set in places people expect a Map.

Yeah, that's the purpose of an abstraction -- to hide implementation
details. `Set`s expose implementation details. Unless it's really much
easier to reuse the whole iteration protocol, it's _probably_ will be fine
(still again will be many confusions initially). But if it's easy to set
default `@@iterator` of `Sets` to just `values`, and kill the `keys()` and
`entries()`, it would be better. Although, once this is done, then the
`againValue` parameter won't make sense in the callback and will need to be
killed as well.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141013/bf33cc19/attachment.html>

[Rick Waldron]

On Monday, October 13, 2014, Domenic Denicola <domenic at domenicdenicola.com>

From: es-discuss [mailto:es-discuss-bounces at mozilla.org <javascript:;>]
On Behalf Of Allen Wirfs-Brock
These only address the `forEach` method though, and not the strange design
of `entries()`, `values()`, and `keys()`.

Can you be more specific, "strange" is subjective and it's not clear what
your referring to.

Rick

I guess a reusability argument could be made, but it seems strange to drive

the API with the idea of wanting to reuse a Set in places people expect a
Map.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141013/c14ef156/attachment.html>

[Dmitry Soshnikov]

On Mon, Oct 13, 2014 at 4:25 PM, Rick Waldron <waldron.rick at gmail.com>

Post by Rick Waldron
On Monday, October 13, 2014, Domenic Denicola <domenic at domenicdenicola.com>

Post by Domenic Denicola
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of
Allen Wirfs-Brock
These only address the `forEach` method though, and not the strange
design of `entries()`, `values()`, and `keys()`.

Can you be more specific, "strange" is subjective and it's not clear what
your referring to.

I think this may bring the thread to bikesheading :) In this case it's less
subjective, since `entries()` simply does not make (big, any?) sense for
sets from the abstraction perspective. As well as `keys()`. Only user-level
matters, implementations do not matter in API designs.

As long as it's already "locked" and was discussed in detail previously, I
think we can just close this one, I already warned about future confusions.
Reusing of a callback function could be considered as a good reason.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141013/415d0d68/attachment-0001.html>

[Axel Rauschmayer]

W.r.t. your last suggestion: that?s how the spec does it. Anything else would definitely not have made sense.

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype-@@iterator
--
Dr. Axel Rauschmayer
axel at rauschma.de
rauschma.de



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141014/86e2b664/attachment.html>

[Erik Arvidsson]

Removing Set.prototype.entries and Set.prototype.keys might make sense. I'm
not really sure why we added them. Probably for consistency.

Post by Dmitry Soshnikov
Are we OK with this? Seems like removing `entries`, `keys` and providing
make it more sense from the abstraction usage perspective.
W.r.t. your last suggestion: that?s how the spec does it. Anything else
would definitely not have made sense.
--
Dr. Axel Rauschmayer
axel at rauschma.de
rauschma.de
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

[Dmitry Soshnikov]

Post by Dmitry Soshnikov
Are we OK with this? Seems like removing `entries`, `keys` and providing
make it more sense from the abstraction usage perspective.
W.r.t. your last suggestion: that?s how the spec does it. Anything else
would definitely not have made sense.

So you're saying that `for-of` iterates only `values`, but `forEach` values
and "keys" (again values)?

```
var aSet = new Set([1, 2, 3]);

for (var v in aSet) {
console.log(v); // 1, 2, 3
}
```

But

```
aSet.forEach((v, v1, theSet) => { ... });

```
Which is basically the same as:

```
for (var [v, v1] in aSet.entries()) {
console.log(v, v1); // 1,1 2,2 3,3
}
```

That's said, if we remove the `entries` and `keys`, then the `v1` naturally
should (?) go away from the callback parameters as well, and in this case
we cannot reuse the callback functions from `Map`s or `Array`s.

Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141014/bd0ad904/attachment.html>