Join GitHub today
[geometry] DOMMatrix constructor is a performance and code portability footgun #346
Consider what happens if one does:
(or in general passes a
Why, exactly, was the overload of the constructor that takes
@zcorpan do you recall why this was set up like this?
OK, but was the goal to remove "overloading" in the sense of using Web IDL overloads, or to reduce the set of things that could be passed in? Because we can easily add
(Note that this situation is quite different from the one for
The goal was to reduce WebIDL overloads.
That said, if people do
@bzbarsky should we add a use counter for this, or do you think we should add the overload regardless of use count?
If we are to add a counter, is it possible to add a counter for each overload on Firefox?
Ah, right! Thanks for digging up those references!
Okay, so it looks like we were just a bit overzealous here, then; we were already mentally committed to having the constructor take a DOMMatrixInit (which you can't distinguish from any other object), and so moved the entire chunk of argument-space over to a static method. Whereas we could have left DOMMatrixReadonly in the constructor's union, satisfying bz's concern in this thread and still fixing the original problem.
That would just mean that you could pass a literal DOMMatrix either in the constructor or the
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: DOMMatrix constructor is a performance and code portability footgun
<dael> github: https://github.com//issues/346
<dael> astearns: krit sent regrets. TabAtkins said makes sense.
<dael> chris: [missed] said he didn't need to be in discussion and happy with what we agreed
<dael> astearns: Proposal was [reads]
<dael> AmeliaBR: I don't entirely understand it either. Right now the constructor allows either a string or an iterrable object. In certain env if you pass another matrix object as a param it gets serialized to a string and reparsed and act like it works. In others it won't happens and it thorws. Concern this is bad
<dael> AmeliaBR: Not sure why sometimes serialized and not others
<dael> AmeliaBR: Request is support another constructor overload that you can construct any matrix by copying values of another matrix object
<dael> heycam: Don't understand why it is worker throws exception
<dael> dbaron: I suspect some serialization or parsing code not exposed to workers.
<dbaron> yeah, the stringifier is Window-only
<dael> AmeliaBR: If behavior in a window is it serializes and parse back again it doesn't sound efficient. Direct cloning is more efficient
<dael> dbaron: Diff is because stringifier is DOM only.
<dael> dbaron: There's consensus in issue. Asking WG to decalre that
<dael> astearns: I don't see anyone saying it's a bad idea to revert the change
<dael> dbaron: And it's part of a change being reverted, not the entire
<dael> heycam: I also don't understand underlying motivation
<dael> astearns: Prop: Add back in the overflow for DOMMatrix readonly to the DOMMatric constructor
<dael> astearns: Objections?
<heycam> s/motivation of removing overloads in general/
<heycam> s/motivation/motivation of removing overloads in general/
<dael> AmeliaBR: Question- do we have multi-impl consensus?
<dael> astearns: I see blink and gecko in comments
<dael> AmeliaBR: Prob okay unless someone from WK objects
<dael> RESOLVED: Add back in the overflow for DOMMatrix readonly to the DOMMatric constructor