update ObjectSet to more closely match the ES6 Set draft?

[petermichaux]

The ES6 Set draft is different than the ObjectSet class used in hormigas.ObjectSet. Matching the ES6 Set draft more closely would likely mean breaking changes to Maria. I've started a discussion on the es-discuss mailing list to find out more about the ES6 Set spec which seems incomplete.

[petermichaux]

es-discuss mailing list thread

https://mail.mozilla.org/pipermail/es-discuss/2013-March/029525.html

[petermichaux]

And now also the following threads.

• https://mail.mozilla.org/pipermail/es-discuss/2013-March/029529.html
• https://mail.mozilla.org/pipermail/es-discuss/2013-March/029530.html
• https://mail.mozilla.org/pipermail/es-discuss/2013-March/029531.html

[petermichaux]

I'm looking at section 15.16 Set Objects in the March 8, 2013 ECMAScript draft which is available at http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts

I'm also looking at version 3 of https://github.com/petermichaux/hormigas which defines hormigas.ObjectSet: the base class for maria.SetModel.

Set constructor can be called with iterable and comparator optional arguments. Currently the comparator is only allowed to be is. hormigas.ObjectSet constructor will add all its arguments as elements of the set. The comparator is essentially ===.

Set.prototype.size vs hormigas.ObjectSet.prototype.length.

Set.prototype.add returns the set object. hormigas.ObjectSet.prototype.add returns true if the set was modified otherwise false.

Set.prototype.clear removes all elements from the set and returns undefined. hormigas.ObjectSet.prototype.empty does the same but returns true if the set was modified otherwise false.

Set.prototype.delete returns true if the set was modified otherwise false. hormigas.ObjectSet.prototype['delete'] returns true if the set was modified otherwise false.

Set.prototype.forEach calls the callback function with three arguments (element, element, set) according to the second NOTE in section 15.16.4.6 but the specification algorithm in the same section has step 8.a.i calling with only two arguments: (element, set). hormigas.ObjectSet.prototype.forEach calls the callback with the two argument version.

Set does not have a reduce method but iteration order of a Set is specified as insertion order. On the other hand, hormigas.ObjectSet iteration order is not specified so hormigas.ObjectSet.prototype.reduce is a bit of an odd duck. If iteration order was specified then both reduce and reduceRight would be appropriate.

Set does not have isEmpty, toArray, some, or every methods.

Set does not have a map method. hormigas.ObjectSet.prototype.map returns an array. Same for filter. It is likely these should return sets of some sort.

Set.prototype.has and hormigas.ObjectSet.prototype.has look to be the same.

[petermichaux]

The goal of modifying hormigas.ObjectSet would be to align it more closely with the ECMAScript Set. This way, one day, maria.SetModel could inherit directly from Set. Due to the changes in hormigas.ObjectSet to align it more with Set, the results on maria.SetModel would be the following.

Likely important breaking changes to maria.SetModel would be

• change length to size
• change empty to clear

Likely less important breaking changes to maria.SetModel would be

• possibly change forEach and the other iterator methods to send three arguments to the callback function. I don't imagine many folks would be using more than the first argument to the callback function anyway. Need a response to https://mail.mozilla.org/pipermail/es-discuss/2013-April/029600.html in order to decide what to do here.
• possibly change the return values of map and filter to sets. This is a tricky issue if maria.ObjectSet has been subclassed. Possibly just remove map and filter as this issue may not have a reasonable solution that can be implemented to execute efficiently. checkit.TodosModel uses map and filter but these could be run on the results of toArray instead (e.g. change .filter( to .toArray().filter().

Non-breaking, optional changes to maria.SetModel would be

• specified iteration order
• add reduceRight

[jamesladd]

I'm in favour of making SetModel closer to the ECMAScript Set.

[petermichaux]

Be careful that the @borrows documentation in maria.SetModel is updated accordingly to any name changes. [obsolete comment]

[petermichaux]

Be careful to rename maria.SetModel.prototype.empty. [I've searched for every use of the word "empty" in the whole project.]

[petermichaux]

Note that the examples and the quick start tutorial use filter, for example. [fixed]

[petermichaux]

There are still some differences between hormigas.SetModel and the ECMAScript proposed Set.

The Set constructor takes iterable and comparator as its arguments. hormigas.SetModel takes a variable number of arguments to be added to the set.

Set.prototype.add returns the set object. hormigas.ObjectSet.prototype.add returns true if the set was modified otherwise false.

Set.prototype.clear removes all elements from the set and returns undefined. hormigas.ObjectSet.prototype.clear does the same but returns true if the set was modified otherwise false.

hormigas.ObjectSet.prototype.forEach only sends the item in the set as the first argument to the callback function. Set.prototype.forEach is currently specified to send the item as the first argument, the item again as the second argument, and the set itself as the third argument. Craziness.

There is nothing like hormigas.ObjectSet.prototype.toArray in the current Set spec.

---

All of these issues can be worked around one day when Set is a viable option and we can shim in maria.SetModel to take care fo any mismatches. There will also be new options like proxies to do multiple inheritance so maria.SetModel can inherit from both maria.Model and Set. This will be important for plugins flexibility.