Re: Interfaces > dictionaries

+1 on coming up with a consistent set of principles we are going to use then changing all the specs to match that

> On Oct 22, 2015, at 7:57 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> 
> I can't bring myself to worry overmuch about this, but the recent
> changes to the ICE stuff goes the opposite way, changing what used to be
> an interface into dictionaries.
> 
> We might want to spend f2f time on "when are dictionaries appropriate,
> when are interfaces approriate, and when should we have interfaces with
> dictionary constructors?"
> 
> AFAIK, more or less:
> 
> - Dictionaries can't be attributes
> - Dictionaries can't be subclassed on return values (so we have to use
> "object" in our WebIDL)
> - Dictionaries have auto-init from a { type: value ... } Javascript
> argument, ignoring superfluous entries
> - Interfaces are the same thing if they have a dictionary-argument
> constructor
> - Dictionaries are pass-by-value; modifying a dictionary has no effect
> on other objects (but modifying an object *in* a dictionary can have)
> - Interfaces can have read-only and read-write members; because of the
> previous point, the topic is irrelevant to dictionaries
> 
> What this means for when we should use one or the other is a good
> question; I'd like to get a common understanding on that first, so that
> we don't continue to flip-flop between them.
> 
> 
> Den 21. okt. 2015 22:54, skrev Martin Thomson:
>> I've submitted a PR that changes a bunch of the support infrastructure
>> for RTCRtpSender.[gs]etParameters() to interfaces.
>> 
>> The PR has a longer discussion of the trade-offs and rationale (included below):
>> 
>>  https://github.com/w3c/webrtc-pc/pull/350
>> 
>> There are very few things in here that are actually mutable as it
>> turns out. Having them as dictionaries is contrary to some of the
>> advice I've received internally on the design of web APIs.
>> 
>> Most of the entire tree can be safely turned into interfaces with
>> readonly attributes. I think that ideally we should move getParameters
>> to an attribute, but I don't want to re-open that discussion again. I
>> get the point of having an atomic setParameters though I think that
>> we'll find that it isn't necessary in practice.
>> 
>> One consequence of this is that it is much more clear now on what can
>> be changed and what cannot. The SSRC was the only one that was
>> previously mutable, which might have been inadvisable with a=ssrc in
>> such heavy use; with the move to RID-based identification, I think
>> that I can accept this being changed.
>> 
>> The main consequence of this change is that you have to take a copy of
>> the parameters if you want to change them. I think that this is an
>> acceptable cost.
>> 
>

Received on Thursday, 22 October 2015 22:38:50 UTC