Set Objects

Allen Wirfs-Brock allen at wirfs-brock.com
Fri Mar 29 17:04:48 PDT 2013


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 http://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 https://mail.mozilla.org/pipermail/es-discuss/2013-March/028963.html Most importantly, no TC39 member stepped up to champion their addition.  You might want to try to revive that thread.





> - - -
> 
> What is and where is section 16.15.5?
> 
> - - -
> 
> Peter
> _______________________________________________
> 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/20130329/a2322fe7/attachment-0001.html>


More information about the es-discuss mailing list