W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > June 2019

[fxtf-drafts] [geometry] DOMMatrix constructor is a performance and code portability footgun (#346)

From: Boris Zbarsky via GitHub <sysbot+gh@w3.org>
Date: Tue, 18 Jun 2019 06:40:34 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issues.opened-457288770-1560840033-sysbot+gh@w3.org>
bzbarsky has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [geometry] DOMMatrix constructor is a performance and code portability footgun ==
Consider what happens if one does:

  `new DOMMatrix(new DOMMatrix())`

(or in general passes a `DOMMatrix` instance to the `DOMMatrix` constructor).  The answer is that, since `DOMMatrix` is not iterable, it will get converted to a string of the form "matrix(stuff)", per https://drafts.fxtf.org/geometry/#dommatrixreadonly-stringification-behavior and then the constructor will either re-parse that string to create a `DOMMatrix` or throw, depending on whether it's running in a `Window` or a worker. This seems like a code portability (between windows and workers) footgun, as well as a performance footgun in the `Window` case.

Why, exactly, was the overload of the constructor that takes `DOMMatrixReadOnly` removed?  It seems to me that we should reinstate it and either make it consistently work (so people can use it) or consistently throw (so people know to not use it and use the `fromMatrix` thing instead)...  The current setup where it kinda works, but only in `Window` scopes doesn't seem great.

@zcorpan do you recall why this was set up like this?


Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/346 using your GitHub account
Received on Tuesday, 18 June 2019 06:40:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:25 UTC