(suggestion/discussion) More unique names for report value types?

[JeroMiya]

Some of the report value types in OSVR.ClientKit have somewhat generic names which are likely to conflict with other libraries. For example, OSVR.ClientKit.Quaternion vs Microsoft.Xna.Framework.Quaternion. In order to make it easier to add a using statement for OSVR.ClientKit without causing ambiguous references, I'd like to propose we rename them in some way that makes then more unique to OSVR or at least less likely to conflict. Some possibilities:

Using OSVR as a prefix, e.g. OSVRQuaternion, OSVRVec3.
Using Value or similar as a suffix, e.g. QuaternionValue.
Using VR as a prefix or suffix? e.g. VRQuaternion, etc...

I'm also ok with using short forms despite the .Net naming conventions discouraging them, for example VRQuat vs VRQuaternion. I think math related types get a pass.

[rpavlik]

I would think that in this case, wouldn't you just use a fully-qualified (or partially-qualified, like ClientKit.Quaternion) name for one of the types, instead of hardcoding what is essentially a namespace into the name?

[JeroMiya]

You can fully qualify the names, but this makes the code verbose and is inconvenient. For example, if I want to use static methods of the Xna Quaternion class, I have to do the full xna framework namespace:

return Microsoft.Xna.Framework.Quaternion.Invert(value);

Which can get pretty tedious in math-heavy code. The problem is made worse if the user needs extension methods from both namespaces, as you need a using statement to expose extension methods, thus making it so both types need to be fully qualified.

It can also lead to confusing code, when some programmers choose to have a using statement for OSVR.ClientKit and others Microsoft.Xna.Framework (or the unity equivalent, or the .Net SIMD equivalent). When reading old code for example, you'll see Quaternion and you'll have to investigate to figure out which type of quaternion it is.

I agree it is somewhat encoding a namespace into the type name, but for such commonly implemented type names I feel it may be justified to make the library easier to consume. Perhaps "Value" or "Report" as a suffix would make it less like a namespace and more descriptive?