I think the basic issue here is that DOM is over-specifying the constraints (I assume because WebIDL makes that most natural?), not the available JS hacks to implement their weirdo type constraints. Lets not feed the misdesign trolls = )
On Tue, Nov 20, 2012 at 2:25 PM, Domenic Denicola < [email protected]> wrote: > For URLQuery in particular, since it's a String->String map, why not just > use a plain-old-JavaScript-object with appropriate interceptions via a > proxy? This provides a much more idiomatic API: > > new URLQuery(object) stays the same > urlQuery.get(name) -> urlQuery[name][0] > urlQuery.getAll(name) -> urlQuery[name] > urlQuery.set(name, values) -> urlQuery[name] = values; use proxy here > urlQuery.add(name, values) -> urlQuery[name].push(...values); use proxy > here > urlQuery.has(name) -> Object.prototype.hasOwnProperty.call(urlQuery, name) > urlQuery.delete(name) -> delete urlQuery[name] > urlQuery.delete(name, value) -> if (urlQuery[name]) { urlQuery[name] = > urlQuery[name].filter(x => x !== value); } > > "use proxy here" means use it to do argument validation and manipulation > of the associated URL object, with percent-encoding. > > The above assumes you want urlQuery[name] to always be an array; > alternatively it could be either a string or array of strings, with > appropriate magic behavior for either. > > > > -----Original Message----- > > From: [email protected] [mailto:es-discuss- > > [email protected]] On Behalf Of Tab Atkins Jr. > > Sent: Monday, November 19, 2012 18:16 > > To: es-discuss > > Subject: "Subclassing" basic types in DOM - best method? > > > > 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...) > > > > ~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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
