Re: Interfaces > dictionaries

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 13:58:09 UTC