Re: [matrix][cssom-view] DOMPoint, DOMPointLiteral definitions

On Sep 28, 2013, at 12:07 AM, Robert O'Callahan <robert@ocallahan.org> wrote:

> I think the cleanest way (at least conceptually*) to support both mutable and immutable rects and also share interface code would be to have three interfaces:
> -- DOMRect is the base interface for both immutable and mutable rects. It defines "current x/y/width/height" state and can expose methods that use that state. Other APIs can take DOMRects and be defined in terms of the current state. It allows read-only access to the current state and does not offer any mutation APIs.
> -- DOMRectImmutable extends DOMRect and adds the invariant that the state never changes. It probably doesn't need to add any new API. (However, being immutable is potentially meaningful to clients, because it allows them to avoid copying, so testing whether a rect is immutable could have value.)
> -- DOMRectMutable extends DOMRect and adds APIs to mutate the rect.
> 
> If we were to just do this directly, the main impact on developers would be that to directly construct a mutable rect they'd have to write "new DOMRectMutable()" which is a little bit more verbose. Could we make "new DOMRect()" return a DOMRectMutable? I think we could at the implementation level, but it might be too magical.
> 
> Another approach would be to name the three interfaces DOMRectBase, DOMRectImmutable, and DOMRect. Then "new DOMRect()" gives you a mutable rect without magic, but OTOH DOMRectImmutable doesn't extend DOMRect, which may be surprising.
> 
> Or we could just take the above directly and have developers write "new DOMRectMutable". I actually prefer this option. I think we should not be adding surprise to the platform just to save a little typing.

Well, then you have 3 objects that need to be implemented, one with inheritance. I am not a huge fan of this.

You could also just introduce DOMRectImmutable and DOMRectMutable and a 

typedef (DOMRectMutable or DOMRectImmutable) DOMRect;

To be honest I still wish we could avoid duplicating every interface. So far we have DOMPoint, DOMRect, DOMQuad, DOMMatrix and ever single interface needs to have a mutable and immutable interface. Each new proposed interface will always actually introduce two. I wish we could move more of magic into WebIDL. Sounds like we can't for this kind of magic.

Greetings,
Dirk


> 
> Rob
> 
> * I.e. this is the way Jeannette Wing would have told me to do it :-).
> -- 
> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr, 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp  waanndt  wyeonut  thoo mken.o w

Received on Saturday, 28 September 2013 05:31:50 UTC