"Subclassing" basic types in DOM - best method?

Rick Waldron waldron.rick at gmail.com
Tue Nov 20 14:56:07 PST 2012



On Tuesday, November 20, 2012 at 5:25 PM, Tab Atkins Jr. wrote:

> On Tue, Nov 20, 2012 at 2:06 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
> > On Tue, Nov 20, 2012 at 3:08 PM, Tab Atkins Jr. <jackalmage at gmail.com>
> > wrote:
> > > Nope, that's not good enough. For example, you have to do input
> > > cleanup (replacing lone surrogates with U+FFFD, escaping &, etc.)
> > > which affects whether two keys are "the same". This affects set()'s
> > > replacing behavior, and add()'s coalescing behavior. Heck, even
> > > without extra cleanup, just the fact that it requires string keys
> > > means you need to eagerly preserve the invariant - foo.set([1,2],
> > > 'bar') and foo.set('1,2', 'bar') should both set the same key. So,
> > > the stringifying must be eager. Additionally, you *must* override the
> > > plain method anyway, since (if the URLQuery is attached to a URL), it
> > > synchronously adjusts the underlying URL as well.
> > > 
> > > However, if you do a normal subclass, then people can do silly things
> > > like "Map.prototype.set(query, key, val);", which would skip
> > > URLQuery's own set() method, avoiding the invariant preservation and
> > > the URL manipulation.
> > > 
> > > We could avoid these problems by only "subclassing" in the sense that
> > > URLQuery.prototype = new Map(); (or Object.create(Map.prototype)),
> > > but not invoking the Map constructor and actually storing data in a
> > > closure-hidden internal Map, so instanceof would work but using Map's
> > > own methods wouldn't.
> > > 
> > 
> > 
> > 
> > class URLQuery extends Map {
> > constructor(url) {
> > // parse the url into a "map", for now
> > // just pretend this is the result of parsing
> > // the url:
> > let parsed = [ ["a", "alpha"], ["b", "beta"] ];
> > super(parsed);
> > }
> > getAll() {
> > // ... implementation details...
> > }
> > }
> > 
> > let query = new URLQuery("http://example.com");
> 
> I'm not sure why you're suggesting this. Deferring to Map's built-ins
> for get(), etc. breaks the basic functionality of the object, as I
> explained in the quoted section immediately above your response. ^_^
> 
> 


I was illustrating the ES6 way to subclass built-ins that result in correctly "inherited" semantics (eg. The array length behaviour gotcha). 

Rick
> 
> ~TJ 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121120/9ecac246/attachment.html>


More information about the es-discuss mailing list