Re: dictionary questions

On 26/08/11 4:03 PM, Allen Wirfs-Brock wrote:
> 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 added a note in 4.2.17 stating that the order isn't necessarily the 
same as property enumeration order.

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

OK.  I've left the spec as is, since it doesn't require default values 
to be instantiated on either the IDL dictionary values (when accepting a 
language-specific dictionary value in) or on ES objects (when returning 
a dictionary value).

Received on Thursday, 8 September 2011 06:24:16 UTC