W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2011

Re: dictionary questions

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 26 Aug 2011 15:36:05 +1200
Message-ID: <4E5714A5.1040106@mcc.id.au>
To: David Flanagan <dflanagan@mozilla.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>
Sorry for the delay in replying here.

On 19/07/11 9:18 AM, David Flanagan wrote:
> I've got a few questions about dictionaries:
>
> 1) §3.4 says that dictionary members are ordered, and that the order is
> the order in which the members appear in the IDL. It is not clear to me
> whether this is intended to apply to inherited dictionary members as
> well. I don't think IDL allows forward references, so inherited members
> obviously come before non-inherited members, but that seems like a
> tenuous connection. I assume that inherited members come first, but it
> seems to me that this ought to be explicitly stated.

I removed the restrictions on forward referencing at some point.

You are right though that I should point out that inherited members come 
before non-inherited ones.

I clarified this:

http://dev.w3.org/cvsweb/2006/webapi/WebIDL/Overview.html.diff?r1=1.357;r2=1.358;f=h

> 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.

I require an ordering just because the algorithm in §4.2.17 fetches all 
the values of properties on an ES object used as a dictionary. :)  This 
is the same as sequence values.

Allen also takes issue with the mandatory copy and type conversion of 
all the values dictionary/sequence.  I did it this way to ensure that 
there would be no ambiguity in the order that property values are 
fetched and side effects run.  The alternative is to not require this 
(make the type conversions "lazy") and rely on specification writers to 
be clear about the order and exactly when dictionary members are looked 
up.  I am a bit worried that spec writers won't do this.  I can of 
course include some wording in the spec warning authors of this.

I'd like to know if others have an opinion on this.

> 3) In §4.2.17, in the algorithm for converting an IDL dictionary to an
> ES Object, shouldn't the Dictionary's default values be used for members
> that are not present? And if not, what is the point of the default values?

The point of the default values is for converting the other way, when 
passing in an ES object with some missing properties.

At the IDL level, dictionary members can be present or not present, 
regardless of whether they have a default value.  I think it makes sense 
then to model that in the converted-to ES Object by omitting properties 
for the values that are not present but have a default value.

Either that, or we change IDL dictionary values so that there is no 
concept of a dictionary member that has a default value but is not 
present.  I don't think I mind either way.  Do you think one makes more 
sense than the other?
Received on Friday, 26 August 2011 03:36:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:04 UTC