- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 19 Jun 2012 14:23:51 +0200
- To: Harald Alvestrand <harald@alvestrand.no>
- Cc: public-webrtc@w3.org
Le mardi 19 juin 2012 à 13:49 +0200, Harald Alvestrand a écrit :
> Simple object:
>
> foo = { x: ww, y: zz }
> InterfaceCall(foo)
>
> InterfaceCall has to check that x and y are present.
>
> Dedicated object:
>
> foo = new FooObject( { x: ww, y: zz } )
> InterfaceCall(foo)
>
> InterfaceCall has to check that foo is of type FooObject.
>
> Do I understand you correctly in what you mean by "using a javascript
> object"?
Indeed. Note that using a dictionary (e.g. FooDict), we can get
verification of the presence of x and y for "free" in WebIDL. (that
said, I think in our case, the main matter is actually about checking
that x and y have valid values)
> If yes, and we have versions 1 and 2, 1 has Object as parameter, 2 has
> FooObject:
>
> 1) version 1 is published
> 2) 10.000 programmers write code for it
> 3) version 2 is published
>
> Is version 2 backwards compatible, or do we have to declare that
> InterfaceCall has a parameter of type "Object or FooObject" in order not
> to break those 10.000 programmers' code?
We could make the type to be (FooDict or FooObject); or we could do a
method overload; or we could provide an interface in FooObject that
turns it into a FooDict (if we don't need to preserve the nature of
FooObject in that context).
> That's exactly the way we broke code in one of the many changes to
> webkitPeerConnection (now deprecatedPeerConnection), I believe; once the
> spec has 10.000 users, I'd like to not make that type of change any more.
I agree that once we have a widely deployed level 1 API, we can't afford
to make backwards incompatible changes; but it seems to me that the
forward compatibility story in these cases is fairly simple.
Dom
Received on Tuesday, 19 June 2012 12:24:21 UTC