Th truth of the matter is that Matrix really had many more methods than really were needed for Matrix.
I just trimmed down Matrix and removed all the methods that were not strictly Matrix related. This includes all Vector3D methods as well as gradient stuff. Here’s how I understand PAYG: 1. Classes should be relatively small and deal with a specific piece of functionality. 2. Additional functionality of components should be implemented as beads (separated into model and view when practical). 3. Common code which is shared across multiple classes should be put in static utility classes to prevent code duplication and unnecessarily inflating classes for rarely used functionality. 4. The utility classes should be small and have specific uses. I’m not sure what else goes into this list. There’s actually two kinds of “paying” in code. The first is in performance, and the second is in terms of code size. I think both should be considered. In fact, there’s very often a trade-off in terms of code size as well. By adding additional classes to split up functionality, you can very often increase the total code size for a client who needs the sum total of the functionality. I think this is something which needs to be taken into account as well when breaking functionality into smaller pieces. On Aug 8, 2016, at 11:22 AM, yishayw <[email protected]> wrote: > I thought I'd share a discussion we had on Matrices as it demonstrates some > problems in deciding how to do things 'the FlexJS way'. > > We needed a TransformBead which uses a matrix as its model. We started out > by implementing the original AS3 matrix, which has members a, b, c, d, tx, > ty and a bunch of utility methods (copyColumnFrom, copyRowTo, rotate, etc.). > The utility methods seemed like clutter for most cases so in keeping with > PAYG we derived an interface that includes that mostly included access > methods to the members (get a, set a, get b, etc.) Now we had the option of > using more lightweight matrix when the utility methods were not necessary. > TransformBead relied on IMatrix implementors, which could be lightweight or > rich with convenience methods. > > This sounds like 'the FlexJS way' but we ditched it for the following > considerations: > > 1) Method calls in JS are slower than direct access of properties. Forcing > models to implement methods rules out using a faster object. > > 2) The supposedly heavyweight model that is rich with convenience methods > doesn't actually result in heavy instances. The methods are all stored once > on the prototype and not duplicated per instance. So using the 'lightweight' > model doesn't really make the difference one might hope it would. > > 3) Removing the convenience methods from the main model opens up the > question of where they should be placed instead. An initial thought is to > implement them on different TransformBeads which require them (e.g. > RotateBead would have a matrixRotate() method), but that's not easily > reusable code. It seems to make sense to allow model manipulations to be > done on the model. > > The main downside I see to the approach we took is that the application size > is unnecessarily bloated. If someone just needs a simple translation > transformation s/he will be confused and perhaps annoyed to see that the JS > code contains all sorts of methods that seem irrelevant. Also, we don't want > FlexJS mobile apps gaining a reputation of being device memory hoggers. > > So I'm still not decided on this. Any thoughts? > > > > -- > View this message in context: > http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Interfaces-Pay-as-You-Go-Performance-tp54380.html > Sent from the Apache Flex Development mailing list archive at Nabble.com.
