W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2015

Re: Interfaces > dictionaries

From: Cullen Jennings <fluffy@iii.ca>
Date: Thu, 22 Oct 2015 16:38:24 -0600
Cc: public-webrtc@w3.org
Message-Id: <E622A7E7-B996-4C26-8974-853B3501FE30@iii.ca>
To: Harald Tveit Alvestrand <harald@alvestrand.no>

+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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:09 UTC