On Nov 19, 2012, at 11:16 PM, "Tab Atkins Jr." <[email protected]> wrote:
> For several things in the DOM and related APIs, we want objects that > are more-or-less the same as some basic ES stuff, like Arrays or Maps, > and which are appropriate to treat as those objects in a generic > manner. > > For example, the URLQuery interface in the URL Standard > <http://url.spec.whatwg.org/#interface-urlquery>, which represents the > query portion (key/value pairs) of a URL, is basically a Map. (It's > missing a few pieces right now, like has() and the iterator-producing > functions, but Anne plans to add them.) > > Ideally, an author could take a library with generic Map-manipulating > functions, pass a URLQuery object in, and have a reasonable chance of > having that just succeed. Hopefully, this should be robust to common > type-checking operations, like doing a structural test, or an > instanceof test. > > Naively, this is doable just by subclassing Map (in the standard proto > way), and overriding the methods, to delegate to the Map methods and > then do additional things. AWB posted some code to WHATWG detailing > how you would do this in ES5 and ES6; it's predictably simple. > > However, URLQuery has some invariants it needs to maintain: it's a > String->String map, not Any->Any. As such, it probably doesn't want > to actually initialize itself as a Map and forward to the Map methods; > instead, it should probably maintain a hidden internal Map and control > the access to that itself, so it can ensure that no non-Strings leak > into the map. > > If we did this, the only reason to continue subclassing Map is to get > instanceof checks to work. Is this acceptable? Are there better > ways, perhaps on the horizon? Any other thoughts? > > (Further examples: NodeList being an Array, URLFragments being an > Array, a few DOM->CSS bridges being Maps...) You can preserve all of those invariants + instanceof checking with proxies, or a subclass that simply over-writes the set methods to blow up on on-strike key/value setting. Either way, it doesn't seem particularly difficult and doesn't, to my mind, reduce the utility of having actual JS-native types as the baseline from which we design/subclass over in DOM. -- Alex Russell [email protected] [email protected] [email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
