On Mon, Jun 2, 2014 at 4:57 AM, Benoit Jacob <jacob.benoi...@gmail.com> wrote:
> > > > 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? > All the methods of DOMMatrix and the helper methods of DOMMatrixReadOnly 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. > SVG really wants to replace its matrix with something better. (You can't even "new" an SVGMatrix) Also, since DOMMatrix will be exposed in CSS, SVG transforms would be returned as DOMMatrix in CSS and SVGMatrix in the DOM which would be very unintuitive. IMO it's silly to have 2 classes that do almost the same thing on the web platform. > 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. > Well, your life would be just as hard if all the other browsers implement it :-) > 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
