Re: [cssom-view] Ability to replace points of a DOMQuad

On Thu, 26 Sep 2013 21:35:16 +0200, Boris Zbarsky <> wrote:

> On 9/26/13 3:06 PM, Simon Pieters wrote:
>> On Thu, 26 Sep 2013 20:02:14 +0200, Boris Zbarsky <>  
>> wrote:
>>> The last time I brought up the issue of getters and setters having
>>> different types on public-script-coord people seemed opposed to the
>>> magic, fwiw.
>> Do you have a pointer?
> and following thread.


     var x = someThingOfTheCorrectType;
     y.z = x;
     assert(y.z === x);

(a) and (b) fail the above. (c) passes, assuming only DOMPoint is the  
"correct type", but fails if the dictionary is also considered to be the  
"correct type".  
suggests using readonly attribute and a method to mutate.

Anne in #whatwg said he likes the convenience and prefers (c) over (a):

# [21:37] <annevk> zcorpan_: (a) seems weird, but I don't really have a  
good reason
# [21:38] <annevk> zcorpan_: I guess if you do obj.x = y and then further  
mutate y, you'd expect that to affect obj.x
# [21:38] <Domenic_> ^ yeah, that
# [21:39] <Domenic_> but that won't work without rethinking a lot, I  
# [21:39] <Domenic_> making it do no validation until consumption time
# [21:39] <zcorpan_> that fails if it's an {x, y}
# [21:40] <annevk> zcorpan_: I think if you pass in something that the  
property does not return you can expect that
# [21:40] <annevk> zcorpan_: similar to setting location to a string
# [21:40] <zcorpan_> on the flip side, if you have a quad and store its  
points as local variables, do you expect them to suddenly not be  
associated with the quad anymore?

Domenic seems to prefer (d), don't coerce on setting, as that's what  
jQuery/d3 would do.

And Tab prefers (a):

On Thu, 26 Sep 2013 21:23:50 +0200, Tab Atkins Jr. <>  

> The "yes", because it's convenient.  The "(a)", because it's
> equivalent to what would happen if you explicitly set the values.

Simon Pieters
Opera Software

Received on Thursday, 26 September 2013 20:39:50 UTC