As Tim points out, vector multiplication implies dot or cross products. These
methods are scaling, not multiplying. Cross product coming in a future commit.
FloatMath contains only shim methods that convert double Math methods to float,
but extends MathUtil so that library users can easily access everything via one
class. MathUtil is used internally so that I can convert pythagoras.f to
pythagoras.d with a few sed expressions. And MathUtil would be what users of
pythagoras.d would want to use for their lerping, clamping and stringifying.
In anticipation of the saying of nay, I offer this: these are value classes,
and in a civilized language, I wouldn't have setters either. "foo.x = x" would
call a setter method over which I had control. However, rather than throwing my
hands up and saying "Gee, I have to have verbose setters, so I guess I better
have verbose getters," I say, "I'll take what I can get."
Methods that verb can be verbs, and we can all agree to understand that methods
that are nouns are getters. foo.width() does not width my foo, it's my foo's
width. foo.invert() inverts up my foo, it is not some attribute of my foo's
nonsensically named invert. I don't want to add my foo's getWidth and
getHeight, I want to add my foo's width and height. So why should I have to
type get over and over again just because I want to protect myself from future
representation change? (Or in this case, to offer immutable views of my value
classes.)
We now have a Transform interface and a bevy of implementations of varying
generality: identity, rigid body, uniform scaling, non-uniform scaling, and
affine.
Along the way, Vector was added, APIs were tidied up, bits were twiddled, but
no platonic shapes were harmed.
Allow inverse to be computed and stored into target transform. Avoid needless
transform creation in concatenate/preConcatente. Still need to rewrite all the
methods that call getFooInstance.
Michael Bayne