Actually, looking at this IDL more closely, I see unneeded invariants causing most of the problem. If URLQuery subclasses Map (assuming we make this possible, which we should), it only needs to promise to hand back strings, not take them. The behavior can simply be defined as toString()-ing the contents when calling "getAll()". There's no reason to re-defined anything about Map here or prevent the normal Map methods from taking any/any as key/value pairs. That URLQuery might, in normal usage, behave this way is a decision for users of the API.
On Tue, Nov 20, 2012 at 10:04 AM, Alex Russell <a...@dojotoolkit.org> wrote: > > On Nov 19, 2012, at 11:16 PM, "Tab Atkins Jr." <jackalm...@gmail.com> > 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 > slightly...@google.com > slightly...@chromium.org > a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
