When I last looked at this, it seemed like a perfect use case for [Traits](http://soft.vub.ac.be/~tvcutsem/traitsjs/tutorial.html). A "Set-like" trait would require definitions for add, delete, and [Symbol.iterator], but provide has, forEach, entries, keys, values, clear, and size, plus any future interfaces.
Then you would implement such set-likes by mixing in the set-like trait into your prototype, which contains type-restricted definitions for add, delete, and [Symbol.iterator] (plus probably some of the other methods for performance reasons). Presumably a future version of ES that contains traits would define set-like, map-like, and other traits that could be used. -----Original Message----- From: es-discuss [mailto:[email protected]] On Behalf Of Tab Atkins Jr. Sent: Monday, August 11, 2014 20:55 To: Allen Wirfs-Brock Cc: Brendan Eich; es-discuss Subject: Re: Overriding Map/etc with get/set hooks? Restarting this thread, because it's still an issue a year+ on. In the Font Loading spec <http://dev.w3.org/csswg/css-font-loading/>, I have a FontFaceSet interface <http://dev.w3.org/csswg/css-font-loading/#FontFaceSet-interface>, which is a Set that contains FontFace objects, plus a few other methods and attributes. Except that it's not a Set, because I can't subclass Sets reliably. Instead, I have to duplicate the entire Set interface *as it exists today*, and have it delegate to a hidden internal Set object. This means that when TC39 extends the Set interface, FontFaceSet will have to be manually updated and bugfixed to contain its own version of the new methods. It also means that when authors define new methods on Set.prototype, they don't apply to FontFaceSet objects unless they manually copy them to FontFaceSet.prototype as well. This is obviously bad. But I can't just directly subclass Set. If I do, then authors can do Set.prototype.add(ffset, "hahaha, I'm a string, not a font face!"), and then the Set is corrupted. I could, of course, defensively write all the FFS operations to check each entry for being a FontFace object first, but that's not quite enough, because *authors* also have to do this when iterating a FFS. It's accepted and idiomatic for all sorts of methods in the web platform to do typechecks on their arguments, and throw errors when they don't match what's expected. It's impossible for me to robustly do this for the Set and Map methods, though. Can we come up with something that allows me to enforce these kinds of checks, like I'm currently doing with my Set-lookalike, and like we do everywhere else in the entire web platform? ~TJ _______________________________________________ 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
