Re: DOMPoint dictionary problem

On Sep 16, 2013, at 6:42 PM, Tab Atkins Jr. <> wrote:

> On Mon, Sep 16, 2013 at 3:46 AM, Robert O'Callahan <> wrote:
>> Making DOMPoint a dictionary, as currently proposed, is a problem since it
>> means other objects (such as the proposed DOMQuad) can't have DOMPoints as
>> attributes. I'm assuming the WebIDL restriction that attributes can't be
>> dictionaries is not easily removed.
> Yes, this is fine with me.
>> I think we probably should make DOMPoint a regular interface. For methods
>> that take DOMPoints as parameters, we can retain the convenient literal
>> syntax for points by adding a DOMPointLiteral dictionary type and using
>> union types, e.g.
>>  DOMPoint convertPoint((DOMPoint or DOMPointLiteral) point);
> You don't even need to do that - as long as their
> attribute/dict-member names match, a DOMPoint *is* a DOMPointLiteral,
> so you can just write the function signature as:
>    DOMPoint convertPoint(DOMPointLiteral point)

I still think it would be useful to resolve decisions on DOMPoint together with a view to the needs of DOMMatrix which uses a Point definition as well. The current definition of Point in DOMMatrix is a dictionary and should have been compatible with DOMPoint dictionary. It is my understanding that this does not need to be the case with an interface DOMPoint. Difference: DOMPoint just has the attributes 'x' and 'y'. Point in DOMMatrix has at least a third parameter 'z' and possibly a forth 'w' (needs a resolution).


> ~TJ

Received on Tuesday, 17 September 2013 08:46:17 UTC