On Thu, Aug 1, 2013 at 5:29 PM, Brendan Eich <[email protected]> wrote: > Tab is still looking for a MapLite (tm) that can be customized with hooks. > Obviously to avoid infinite regress, the MapLite bottoms out as native, and > the hooks are on the outside (in Map). Tab, do I have this right?
Right. Map has a medium-sized interface, with several methods that don't provide new capabiltiies, but only convenience/performance. As well, I expect the interface to grow over time. Making a Map subclass that needs to audit its data on input or output is thus difficult, because when a new method gets added to Map, either it's able to pierce through your interventions and get at the raw data directly, or it simple doesn't work until you update. Even for the existing methods, you have to manually override the conveniences; just overriding delete() just protect you against a clear(). MapLite has the smallest possible useful semantics for a Map (basically, the same semantics that the spec uses in terms of meta-operations), and thus is useful as an interception target. You can then just subclass Map and only override the MapLite at its core, secure in the knowledge that new methods will Just Work (tm) in terms of the provided bedrock operations on the MapLite. > The even simpler course is to keep Map as spec'ed and make DOM or other > specs work harder. Trade-offs... The reason I'm really pushing on this is that it's not just DOM (we've already made the trade-off there, by adding [MapClass] to WebIDL), but user-space as well. I can't make a safe Counter class that's built on a Map unless I make the tradeoff above. But this is a tangent. ^_^ ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
