User talk:Cron Stardust/LLVector Spec

Using returned references more completely

While I converted all the method signatures that had a return type of void to const LLVector&, there are still several methods that return what seems like semi-useless noise: BOOL and NUM. I'm not counting the ones that should return those types, but methods like normalize, which has no business returning NUM. The in-source documentation says "Normalizes and returns the magnitude of LLVector..." Ok... Ummm.... Isn't the result of normalization SUPPOSED TO BE 1.f?!!?!!? Wouldn't it be better if it returned const LLVector& so that we could do: <cpp> LLVector vec(); vec.normalize().scale(3.f); </cpp> I certainly think so, but I'll leave this change to stew for a bit - I've got bigger spuds to fry ATM. Cron Stardust 15:40, 6 April 2014 (PDT)

clear() vs setZero()

In prediction of the argument, I chose setZero because of the greater semantic meaning: setZero explicitly states, right up front, that it is setting the vector to a magnitude of 0. A potential argument in favor of clear is that it is easier to type: less characters and no shift-key. But this argument is based on laziness instead of code clarity - after all, why not just go with s0()? Kinda ridiculous IMNSHO.

A stronger argument would be that while setZero carries the meaning of set magnitude to 0 clear would carry the meaning of clear all members - the difference being moot in all cases but LLVector4: a 4-vector of <0,0,0,1> still has a magnitude of 0, but it is not fully cleared. To counter this argue that that is the correct meaning and result: setZero would work with the XYZ components, while some other method would work on switching the meaning of the vector: a vector with a W-component of 0 is an untranslatable direction+magnitude, while a vector with a W-component of 1 is a point in 3D space with reference to some origin and therefore can be translated. Furthermore, there should be some extra set of methods for 4-vectors to explicitly set the type of vector so as to retain the semantic meaning of the two kinds of vector it can represent - especially since, as far as I currently understand, any other value then 0 or 1 in the W-component is most likely a bug - I'm not sure at this moment, without re-analyzing the matrix multiplication, what the effect of various values other than 0 or 1 would be! Cron Stardust 16:50, 11 April 2014 (PDT)

Return const or not?

The whole goal of the changing return types from void to a reference was method chaining. However it seems that I flubbed: returning a const reference does NOT allow method chaining. Instead I should just return a reference. API change in progress after a quick review. Cron Stardust 00:38, 20 April 2014 (PDT)

After review, and verifying that the viewer still functions correctly after the change, I have done so. Commit to repo coming soon. Cron Stardust 00:41, 20 April 2014 (PDT)

Data types in variable names (mdV vs mV)

It's come to my attention that changing the array name in LLVector3d from mdV to mV is somewhat controversial. This notation is distinctly Systems Hungarian notation, and while the war is still mostly in progress, the winning side seems to be against its use - at least the Systems Hungarian.

The "m" prefix would be Apps Hungarian, and could also be removed in all classes, but that would entail determining a name that would be longer - though I'd argue that it would be a good thing: the existing variable name carries very little semantic meaning; mV means "member, Vector". To me a better name would be "components" - the terminology used in mathematics for the parts of a vector. However that variable name is quite long... "vc" for vector component?

Anyway, the point was that the vector types that are only differentiated by the number of bits per component should have identical APIs to facilitate converting the code from one to the other: eg. when it is determined that a float-based type doesn't have enough precision or, conversely, if the double-based type is shown to not be needed. The need for differentiating the type in the name is alleviated by a combination of the IDE being able to tell you what the type if any variable is at a glance, and the compiler emitting a warning if you do something stupid - like double d = 3.0; float m = d; A good IDE will even highlight the implicit conversion from double to float as a potential problem area. For those of us who code with text editors instead of IDEs... Well we've got what we asked for: a simple fast editor, with the caveat that we have to remember what we are working with. (Yes, I rarely use an IDE - too big and slow most of the time.)

All that said, these types are just shy of deprecated anyway: it'd be better if everything was switched over to LLVector4a - much better performance. Cron Stardust 21:09, 21 April 2014 (PDT)