Open osrf-migration opened 8 years ago
Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
Actually, there is a bit of different behavior that can be expected.
For example, we added Transpose
and Transposed
methods to the matrix classes in pull request #74:
public: void Matrix3::Transpose()
public: Matrix3<T> Matrix3::Transposed() const
The Transpose
method acts in place on an existing object, while Transposed
is const
, so it doesn't affect the base object, but returns a new value.
I think we could do a similar thing for Normalize
with the vector classes and perhaps Quaternion as well:
Normalize
for in-place modification of an objectNormalized
for creating a new objectI realize this doesn't directly address the title of this issue, which is about return values, but changing that will break API/ABI, so we can wait until the next major release to change the return type if we decide to do so.
Original comment by Amitoj (Bitbucket: amtj).
I tried the bug, please have a look. https://bitbucket.org/amtj/ign-math/commits/all
Regards.
I think this is still inconsistent:
I agree with the solution proposed by @scpeters above, the problem is that it will be too disruptive. We can't tick-tock deprecate Vector3::Normalize()
, we would have to change the return type from Vector3
to void
on ign-math7
. I think we need to balance the API improvement with the impact on users. Maybe since a lot will change in ign-math7
due to #101, maybe it's a good time to also make this change? What do you think, @scpeters ?
About the Quaternion to solve this issue, we should add Normalized to the class?
Nice catch, it already has void Normalize
, so we could add Quaternion<T> Normalized
.
Nice catch, it already has void Normalize, so we could add Quaternion
Normalized.
So, I'm planning to work on the implementation of the Quaternion<T> Normalized
method.
Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).
We should make these consistent.