- From: Simon Pieters <simonp@opera.com>
- Date: Thu, 26 Sep 2013 16:00:42 +0200
- To: "Dirk Schulze" <dschulze@adobe.com>, "Domenic Denicola" <domenic@domenicdenicola.com>
- Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Thu, 26 Sep 2013 15:35:54 +0200, Domenic Denicola <domenic@domenicdenicola.com> wrote: >> Hmm, then every method that can take both as argument, also must >> specify both every time. Beside that, you also need to implement each >> interface twice. One for the mutable case, on for the immutable. Means >> you have duplication all over the platform. That sound suboptimal. > > Shouldn't any interfaces that take these as arguments actually accept > anything in the form { left, right, top, bottom } or { left, right, > width, height }? No real JS API would force you to pass through a > constructor when an object literal would do. We support that for DOMPoint (by also defining a dictionary), but not for DOMRect. I think if we want to do this everywhere, it's better to change WebIDL to allow user objects than to define dictionaries for everything. Does it make sense everywhere? It doesn't make sense for e.g. Node#appendChild(). > Stated in terms of proto-JSIDL semantics (which admittedly are not a > real thing yet), for arguments you would not use the DOMRect brand, but > instead the ToRect conversion, which takes objects of the above two > forms and returns a normalized version for your method's algorithm to > operate on (or throws a TypeError if the incoming object does not match > either of those two forms). > > DOMRect still has use as a return value, and DOMRect instances pass > through ToRect just fine, but using DOMRect on the input side as well as > for return values makes for very awkward APIs, of the type this mailing > list is designed to help avoid. -- Simon Pieters Opera Software
Received on Thursday, 26 September 2013 14:01:14 UTC