[fxtf-drafts] [geometry-1] `DomMatrixReadOnly` is missing `preMultiply()` method (and the idea of better mutable vs immutable patterns) (#587)

trusktr has just created a new issue for https://github.com/w3c/fxtf-drafts:

== [geometry-1] `DomMatrixReadOnly` is missing `preMultiply()` method (and the idea of better mutable vs immutable patterns) ==
`DOMMatrix` has mutating `multiplySelf()` and `preMultiplySelf()`, while `DOMMatrixReadOnly` has only the non-mutating `multiply()` but not `preMultiply()`.

It would be nice to add `preMultiply` for consistency. Similar for other `*ReadOnly` geometry classes if needed.

As an alternative, instead of adding more methods to `*ReadOnly` as it has elsewhere been discussed that the `*ReadOnly` pattern is a direction we wish we didn't take (that's why there's `DOMQuad` but not `DOMQuadReadOnly`), we should consider adding a new pattern of methods for working with immutability vs not.

I propose adding `clone()` and `copy()` methods, and then people can pursue immutability like so:

```js
const mat1 = new DOMMatrix(...)
const mat2 = new DOMMatrix(...)

const mat3 = mat1.clone().preMultiplySelf(mat2)
```

or

```js
const mat1 = new DOMMatrix(...)
const mat2 = new DOMMatrix(...)

const mat3 = new DOMMatrix()
mat3.copy(mat1).preMultiplySelf(mat2)
```

As a real-world example, pretty much all Three.js classes have clone() and copy() methods. Many of their methods also accept targets, for example `obj.doSomething()` (writes to self) vs `obj.doSomething(other)` writes to `other` instead of self.

I believe that the approach Three.js takes is nice because it is more concise (methods that can be mutable or not mutable, insead of double the amount of methods for mutable vs not).

Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/587 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 28 December 2024 02:34:48 UTC