Re: dictionary questions

On Aug 25, 2011, at 8:36 PM, Cameron McCormack wrote:

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

While I would like to find a way to eliminate such  mandatory  conversions, I don't have a issue with specify a conversion order for the members as long as that order does suggest or require that for-in enumeration uses that same order.  In other words it is ok for (actually desirable) for such conversions to specify an ordering, just make sure that nobody confuses that ordering with for-in enumeration ordering.

A statement about this in 4.2.17 would probably satisfy me.

> 
> 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?
I would think that the meaning of a default value, is that it specifies the value to be used by a client of a dictionary when the corresponding member is not present.  A client could be an implementation of a Web API or it could be user code that is is return such a dictionary form a Web API. In either case, the client should be able to test for the actual existence of such members.   For interface specification purposes I don't see why you would need to require the work of actually fully populating such dictionary when they cross call boundaries. In most cases you will just be requiring unnecessary memory allocations and deallocations.

 Allen