Map-like objects people will want include: - something that looks like a Map, but backed by something other than [[MapData]], like DOM attributes, a JS object's properties, a hash table that doesn't retain entry order, or a key-value store; - an observable Map; - a Map that generates new entries, with default values, if you .get() a key that isn't in the map (cf Ruby Hash#default_proc); - an immutable Map; - a Map that type-checks values, as well as keys; - a Map with different GC semantics.
Tab, is your present use case in CSS Variables (key coercion) the one common use case worth addressing? How would we know? Alternatively, can we cover all the likely needs by adding hooks? Counterproposal: address this in WebIDL. Add a magic [Maplike] tag that means something like: - the prose for this interface includes an algorithm for computing the list of this object's entries (as key-value pairs, like [[MapData]]) - the prototype for this interface has methods has, get, forEach, entries, keys, and values (and a .size accessor property), and they are defined in terms of that algorithm unless the prose says otherwise - the prose for this interface includes algorithms for adding and deleting entries from this object - the prototype for this interface has methods set, delete, and clear, defined in terms of that algorithm unless the prose says otherwise It would be shorthand for making non-Map objects that walk and quack like a Map. From the spec author's perspective, this would eliminate most of the boilerplate, and it seems more flexible than hooks. All the methods (and the .size getter) would be non-generic, so there would be no danger of one type of Map being corrupted by someone .apply()ing a method from another type of Map. (Maybe this can be done with a Maplike interface and implements-statements instead—I don't really know WebIDL.) -j
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
