- 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