- From: David Flanagan <dflanagan@mozilla.com>
- Date: Tue, 19 Jul 2011 14:39:45 -0700
- To: Ian Hickson <ian@hixie.ch>
- CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
On 7/19/11 11:03 AM, Ian Hickson wrote: > On Mon, 18 Jul 2011, David Flanagan wrote: >> 2) On the other hand, why do dictionary members need an ordering at all? >> §3.4 forbids duplicate member names, and doesn't allow dictionaries to >> shadow or redefine the members they inherit. So I can't see anywhere >> that the ordering matters. It would simplify the algorithms in §4.2.17 >> to remove the ordering altogether. > We might not need ordering, but it's important that anywhere were an order > can be observed (e.g. for-in loop in JS) every UA have the same order. > But the JS representation of a dictionary object is a plain old JavaScript object, right? And the only place I've seen dictionaries used so far is in the new Event constructors. I gather that dictionaries are a specification mechanism that allows programmers to pass JS objects to IDL methods, or that that will be their primary use-case at least. To a web developer, the observable iteration order will be whatever order the web developer defines the properties of the JS object in. What am I missing? Are there any APIs yet that return or mutate dictionaries? I suppose in that case the iteration order should be specified or it should be explicitly specified as undefined. (That brings me back to my 3rd question, though: if an interface exposes a dictionary as the return value of an operation or as the value of an attribute, should the JavaScript object include default values for members that are not present? And if so should they be own properties or inherited properties?) David
Received on Tuesday, 19 July 2011 21:40:13 UTC