On Tue, May 21, 2013 at 4:19 AM, Brendan Eich <[email protected]> wrote: > David Bruant wrote: >> This description ("arbitrary string keys", "bidirectional link with style >> rule") suggests that you want a proxy (canonical values are in the style >> rule, the proxy is just a façade with a bit of validation/coercion logic). >> That's the sort of use case they've been introduced for. > > I don't see why a proxy is required if the API is get/set/has (like Map's). > We're not making properties appear without knowing their names, so this is > not a proxy use-case on its face. > > Of course, coercing key type makes the API not Map. So if the > bi-directionality is important, this would be a custom Map-like class. > > So Tab: why do you want to abuse Map instead of make a custom class?
Restating from my earlier post: 1. when someone asks "is this Map-like?" in an appropriately idiomatic JS way, they get a "yes" answer. 2. when someone adds a new function to Maps in an appropriately idiomatic JS way, the method also applies to this object 3. when JS expands the set of built-in methods for Map, it also gets applied to this object without me having to update my spec 4. for all the existing Map methods, I get identical/equivalent methods without having to manually redefine every single one of them All of these follow from the basic statement that *this is a map*, because it clearly is. It's limited to string keys and values, but that's just some coercion rules. Every single operation defined on Maps currently is meaningful and useful for this object, and virtually any method you can imagine adding to Maps in the future is also meaningful and useful. Ducktyping this as a Map is terrible, because it breaks #2/3/4, and arguably #1 depending on what you consider an "appropriately idiomatic" way of asking if something is Map-like. Just subclassing Maps and providing my own get/set functions is not as terrible, but still bad for a few reasons: I need to study the ES spec very carefully to figure out which operations are "basic" (interact directly with [[MapData]] rather than going through existing operations) and redefine all of them, and anyone who ever does something like Map.prototype.set.call(myObj, ...) will break the invariants I need maintained, with mysterious and undefined results. This should be super-simple - I just want to supply a custom object as the [[MapData]] which can intercept sets so it can coerce the values beforehand. In every other way, this is a Map. ~TJ _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
