- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 10 Jun 2013 18:43:04 -0700
- To: "public-script-coord@w3.org" <public-script-coord@w3.org>
Ugh, and of course, after letting the email sit for 15 minutes while I thought about it, I think of more things to add 15 seconds after sending it. On Mon, Jun 10, 2013 at 6:36 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > The interface MAY manually define the get() and has() methods; > otherwise, they're automatically defined in terms of the "map tuples". > The interface MAY manually define set() and delete() methods; > otherwise, they automatically throw TypeErrors with a message > indicating that the interface is readonly. (Can we make the methods > auto-throw if the interface is used on a readonly attribute?) > > The remaining Map methods (currently just clear() and forEach()) MAY > be manually defined; otherwise, they're automatically defined as in > <https://gist.github.com/jorendorff/5662673>. All of these methods' signatures must match the general Map method signatures, and the declared key/val types specified in the extended attribute. For example, if declared as [MapClass(DOMString, long)], the get() method must be defined as "long get(DOMString)". The set() method must be defined as "void set(DOMString, long)". The delete() method must be defined as "boolean delete(DOMString)", with the boolean being true if anything was deleted, and false otherwise. Etc. A note might be useful in the spec as well, noting that *all* of the Map.prototype built-in methods are shadowed on the interface, and the built-ins, if explicitly called on the object like "Map.prototype.get.call(obj, key)", will throw, because the object lacks a [[MapData]] internal property. The use of Map.prototype on the prototype chain is to aid with type checks ("obj instanceof Map" works), and to allow author-defined extensions placed on Map to automatically be available on the interface as well. ~TJ
Received on Tuesday, 11 June 2013 01:43:57 UTC