- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 May 2011 04:33:31 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248 --- Comment #38 from Cameron McCormack <cam@mcc.id.au> 2011-05-26 04:33:26 UTC --- I'm leaning towards adding a "dictionary" definition. To run with the IndexedDB example: dictionary ObjectStoreOptions { DOMString keyPath; boolean autoIncrement; }; interface IDBDatabase : EventTarget { ... IDBObjectStore createObjectStore (in DOMString name in optional ObjectStoreOptions optionalParameters); }; Dictionaries wouldn't have an "interface object" or "interface prototype object". Dictionary members can be present or not present, and the prose for an interface can see this at the IDL level. We could decide to add default values to the dictionary members if people really want it; otherwise, I'd say to just leave it to prose for now. In JS dictionaries are represented by plain objects that you do a [[HasProperty]] to determine if the dictionary member was specified, and a [[Get]] to get its value. (Alternatively, we could do a [[Get]] and treat undefined as meaning not specified.) In the implementation of createObjectStore, it would get the values for each dictionary member in the order that they appear in the IDL (so first keyPath then autoIncrement). There'd be no restriction on which argument positions dictionaries could be used in, so it's not quite the same as adding keyword argument functionality to operations. As with sequences, dictionaries could be used as operation return types too, but not as the type of an attribute (or exception member). This does not help structured cloning, but that seems like a special enough case to me to leave it to the HTML spec to define rather than including Web IDL machinery for it. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Thursday, 26 May 2011 04:33:37 UTC