2014-06-01 23:19 GMT-04:00 Rik Cabanier <caban...@gmail.com>: > > > > On Sun, Jun 1, 2014 at 3:11 PM, Benoit Jacob <jacob.benoi...@gmail.com> > wrote: > >> >> >> >> 2014-05-31 0:40 GMT-04:00 Rik Cabanier <caban...@gmail.com>: >> >> Objection #3: >>>> >>>> I dislike the way that this API exposes multiplication order. It's not >>>> obvious enough which of A.multiply(B) and A.multiplyBy(B) is doing A=A*B >>>> and which is doing A=B*A. >>>> >>> >>> The "by" methods do the transformation in-place. In this case, both are >>> A = A * B >>> Maybe you're thinking of preMultiply? >>> >> >> Ah, I was totally confused by the method names. "Multiply" is already a >> verb, and the method name "multiply" already implicitly means "multiply >> *by*". So it's very confusing that there is another method named multiplyBy. >> > > Yeah, we had discussion on that. 'by' is not ideal, but it is much shorter > than 'InPlace'. Do you have a suggestion to improve the name? >
My suggestion was the one below that part (multiply->product, multiplyBy->multiply) but it seems that that's moot because: > > >> Methods on DOMMatrixReadOnly are inconsistently named: some, like >> "multiply", are named after the /verb/ describing what they /do/, while >> others, like "inverse", are named after the /noun/ describing what they >> /return/. >> >> Choose one and stick to it; my preference goes to the latter, i.e. rename >> "multiply" to "product" in line with the existing "inverse" and then the >> DOMMatrix.multiplyBy method can drop the "By" and become "multiply". >> >> If you do rename "multiply" to "product" that leads to the question of >> what "preMultiply" should become. >> >> In an ideal world (not commenting on whether that's a thing we can get on >> the Web), "product" would be a global function, not a class method, so you >> could let people write product(X, Y) or product(Y, X) and not have to worry >> about naming differently the two product orders. >> > > Unfortunately, we're stuck with the API names that SVG gave to its matrix. > The only way to fix this is to duplicate the API and support both old and > new names which is very confusing, > Sounds like the naming is not even up for discussion, then? In that case, what is up for discussion? That's basically the core disagreement here: I'm not convinced that just because something is in SVG implies that it should be propagated as a "blessed" abstraction for the rest of the Web. Naming and branding matter: something named "SVGMatrix" clearly suggests "should be used for dealing with SVG" while something named "DOMMatrix" sounds like it's recommended for use everywhere on the Web. I would rather have SVG keep its own matrix class while the rest of the Web gets something nicer. > > >> Objection #4: >>>> >>>> By exposing a inverse() method but no solve() method, this API will >>>> encourage people who have to solve linear systems to do so by doing >>>> matrix.inverse().transformPoint(...), which is inefficient and can be >>>> numerically unstable. >>>> >>>> But then of course once we open the pandora box of exposing solvers, >>>> the API grows a lot more. My point is not to suggest to grow the API more. >>>> My point is to discourage you and the W3C from getting into the matrix API >>>> design business. Matrix APIs are bound to either grow big or be useless. I >>>> believe that the only appropriate Matrix interface at the Web API level is >>>> a plain storage class, with minimal getters (basically a thin wrapper >>>> around a typed array without any nontrivial arithmetic built in). >>>> >>> >>> We already went over this at length about a year ago. >>> Dirk's been asking for feedback on this interface on www-style and >>> public-fx so can you raise your concerns there? Just keep in mind that we >>> have to support the SVGMatrix and CSSMatrix interfaces. >>> >> >> My ROI for arguing on standards mailing on matrix math topics lists has >> been very low, presumably because these are specialist topics outside of >> the area of expertise of these groups. >> > > It is a constant struggle. We need to strike a balance between > mathematicians and average authors. Stay with it and prepare to repeat > yourself; it's frustrating for everyone involved. > If you really don't want to participate anymore, we can get to an > agreement here and I can try to convince the others. > I'm happy to continue to provide input on matrix API design or other math topics. I can't go spontaneously participate in conversations on all the mailing lists though; dev-platform is the only one that I monitor closely, and where I'm very motivated to get involved, because what really makes my life harder is if the wrong API gets implemented in Gecko. > >> Here are a couple more objections by the way: >> >> Objection #5: >> >> The isIdentity() method has the same issue as was described about is2D() >> above: as matrices get computed, they are going to jump unpredicably >> between being exactly identity and not. People using isIdentity() to jump >> between code paths are going to get unexpected jumps between code paths >> i.e. typically performance cliffs, or worse if they start asserting that a >> matrix should or should not be exactly identity. For that reason, I would >> remove the isIdentity method. >> > > isIdentity() indeed suffers from rounding errors but since it's useful, > I'm hesitant to remove it. > In our rendering libraries at Adobe, we check if a matrix is *almost* > identity. Maybe we can do the same here? > Since you say that isIdentity() is useful, can you provide an example of a valid use case for it, to make this conversation concrete? Switching isIdentity() to use a fuzzy comparison, as IIUC you say Adobe uses internally, doesn't change fundamentally the problem here, which is that there is a sudden jump. The discontinuity is merely moved elsewhere. Any discontinuous matrix function, in particular any function taking a matrix and returning a boolean, is easy to misuse. I'm willing to believe that Adobe uses that for a precise, valid purpose though --- but here in a DOMMatrix interface we can't assume any specific purpose. Benoit _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
