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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
