Set Objects

# Peter Michaux (12 years ago)

Some comments and questions about the Set draft specification...


Section 15.16 begins with the following which seems to need an English clean-up.

Set objects are collections of ECMAScript language values. A distinct value may only occur once as elements of a Set’s collection. Distinct values as discriminated using the a comparision algorithm that is selected when the Set is created.

Set objects are collections of ECMAScript language values. A distinct value may only occur once as an element of a Set. Distinct values are discriminated using the comparison algorithm that is selected when the Set is created.


Section 15.16.1

it initializes its this value with the internal state necessary to support the Set.prototype internal methods.

What does that mean? Cannot the caller set the value of "this" using the "call" or "apply" methods?


Section 15.16.1

The Set constructor is designed to be subclassable. It may be used as the value in an extends clause of a class definition. Subclass constructors that intend to inherit the specified Set behaviour must include a super call to Set.

Why is this in section 15.16.1 which is about calling Set as a function? Isn't inclusion of the above in 15.16.2 sufficient?


Section 15.16.1.1

step 4 missing [[

step 10 font size smaller inside [[]]

NOTE mentions Map, key, value which seems like it might be a copy and paste error from the Map section of the specification. Does the iterator really need to return two-element array-like objects in this case?


Section 15.16.2.1

step 2 "be the be the"

NOTE mentions an "iterable" parameter but there is no indication in this section where that would be in the parameter list.

NOTE mentions "values" but section 15.16.1.1 doesn't indicate how that would be used rather than @@iterator.


15.16.4.2

I think it would be useful if Set.prototype.add could take multiple values

Instead of

set.prototype.add(a);
set.prototype.add(b);
set.prototype.add(c);

allow the following

set.prototype.add(a, b, c);

It would be useful to know if the set was modified as a result of the add call. Step 8.a.i return false. Step 9 return true. This would allow a model layer in an MVC application to know if a "change" event needs to be fired or not.


15.16.4.3

Should 15.16.4.2's step 5 be inserted between 15.16.4.3's steps 4 and 5? This would define the content of entries.

It would be useful to know if the set was modified as a result of the clear call. For a previously empty set, clear would return false. Otherwise true.


15.16.4.4

Delete is good because it returns true or false indicating if the set was modified or not.

The add, clear, and delete method's have very inconsistent return values. Returning true or false for all depending if the set was modified or not would be great.

Could delete take multiple arguments, all of which will be deleted from the set?


15.16.4.6

Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set.

The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior.

The length property of forEach is defined to be 1. The length of other Set.prototype methods is not defined.


15.16.4.8

A set has no concept of "keys". The existence of Set.prototype.keys seems inappropriate for a set.


Will the following methods be added to Set.prototype?

some every reduce filter map toArray union intersection difference (other Mathematical set operations?)


What is and where is section 16.15.5?


Peter

# Rick Waldron (12 years ago)

Please file spec bugs here: bugs.ecmascript.org

# Allen Wirfs-Brock (12 years ago)

On Mar 29, 2013, at 3:02 PM, Peter Michaux wrote:

Some comments and questions about the Set draft specification...

If possible, bugs in ES spec. drafts should be reported using bugs.ecmascript.org

That way I can track them and they don't get lost among the general es-discuss traffic.

answers to non-bug questions below.

... Section 15.16.1

it initializes its this value with the internal state necessary to support the Set.prototype internal methods.

What does that mean? Cannot the caller set the value of "this" using the "call" or "apply" methods?

Typically constructor functions initialize the object passed into as the this value (however it is accomplished, including call and apply). That's all this boilerplate is saying.


Section 15.16.1

The Set constructor is designed to be subclassable. It may be used as the value in an extends clause of a class definition. Subclass constructors that intend to inherit the specified Set behaviour must include a super call to Set.

Why is this in section 15.16.1 which is about calling Set as a function? Isn't inclusion of the above in 15.16.2 sufficient?

It really is about calling Set as a function. In particular, a super call in a subclass constructor will call Set "as a function".

In general, this language is ensuring that Set is implemented in a manner that enables subclassing.


Section 15.16.1.1

step 4 missing [[

step 10 font size smaller inside [[]]

NOTE mentions Map, key, value which seems like it might be a copy and paste error from the Map section of the specification. Does the iterator really need to return two-element array-like objects in this case?


right bogus copy and pasted note.

Section 15.16.2.1

step 2 "be the be the"

NOTE mentions an "iterable" parameter but there is no indication in this section where that would be in the parameter list.

NOTE mentions "values" but section 15.16.1.1 doesn't indicate how that would be used rather than @@iterator.


15.16.4.2

I think it would be useful if Set.prototype.add could take multiple values

Instead of

set.prototype.add(a); set.prototype.add(b); set.prototype.add(c);

allow the following

set.prototype.add(a, b, c);

It would be useful to know if the set was modified as a result of the add call. Step 8.a.i return false. Step 9 return true. This would allow a model layer in an MVC application to know if a "change" event needs to be fired or not.


You might want to bring this up as a separate item on es-discuss. There was a recent thread relating to add method (and set method of map) returning the collection (originally they were specified to return undefined). You are presenting a different perspective which may not have been represented on the original thread.

15.16.4.3

Should 15.16.4.2's step 5 be inserted between 15.16.4.3's steps 4 and 5? This would define the content of entries.

It would be useful to know if the set was modified as a result of the clear call. For a previously empty set, clear would return false. Otherwise true.

see above


15.16.4.4

Delete is good because it returns true or false indicating if the set was modified or not.

The add, clear, and delete method's have very inconsistent return values. Returning true or false for all depending if the set was modified or not would be great.

Could delete take multiple arguments, all of which will be deleted from the set?


15.16.4.6

Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set.

The intent is that all forEach methods use the same callback signature. This is explained in the second note.

The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior.

Yes, but this is just a note. The specification algorithm normatively exhibit this behavior which is where it really counts.

The length property of forEach is defined to be 1. The length of other Set.prototype methods is not defined.


15.16.4.8

A set has no concept of "keys". The existence of Set.prototype.keys seems inappropriate for a set.

All the built-in iterable collectons have keys, values, and items methods. As the note says, a set item has have the same value for both its key and value.


Will the following methods be added to Set.prototype?

some every reduce filter map no current plans toArray use Array.from(mySet)

union intersection difference (other Mathematical set operations?)

There was a short but inconclusive discussion of these recently esdiscuss/2013-March/028963 Most importantly, no TC39 member stepped up to champion their addition. You might want to try to revive that thread.

# Peter Michaux (12 years ago)

On Fri, Mar 29, 2013 at 5:04 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

On Mar 29, 2013, at 3:02 PM, Peter Michaux wrote:

15.16.4.6

Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set.

The intent is that all forEach methods use the same callback signature. This is explained in the second note.

The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior.

Yes, but this is just a note. The specification algorithm normatively exhibit this behavior which is where it really counts.

In that case, I think the second note might be an error. The specification algorithm has the following

8.a.i) Let funcResult be the result of calling the [[Call]] internal method of callbackfn with T as thisArgument and a List containing e and S as argumentsList.

That means the callback function is called with only two arguments not three as mentioned in the second note.

Peter

# Allen Wirfs-Brock (12 years ago)

On Apr 3, 2013, at 9:17 PM, Peter Michaux wrote:

On Fri, Mar 29, 2013 at 5:04 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

On Mar 29, 2013, at 3:02 PM, Peter Michaux wrote:

15.16.4.6

Why will callbackfn be called with the first two parameters being the same? That does not seem like the most practical or intuitive behavior for a set.

The intent is that all forEach methods use the same callback signature. This is explained in the second note.

The third NOTE about visiting elements that are deleted or added during iteration is excellent. Browsers have certainly varied in their behavior.

Yes, but this is just a note. The specification algorithm normatively exhibit this behavior which is where it really counts.

In that case, I think the second note might be an error. The specification algorithm has the following

8.a.i) Let funcResult be the result of calling the [[Call]] internal method of callbackfn with T as thisArgument and a List containing e and S as argumentsList.

That means the callback function is called with only two arguments not three as mentioned in the second note.

Actually, the code in the algorithm was wrong. I've fixed it to pass three arguments.

Thanks,