Le 07/09/2011 08:27, Sébastien Brisard a écrit :
True enough.
Maybe the use of one those two could be strongly discouraged.
I personally was puzzled the first time I saw those two methods. I was
even wondering wether one of them would not return a shallow copy
(when possible), while the other would return a deep copy. Had to look
at the source to finally realize that toArray() and getData() do
exactly the same thing.
As for incompatible change, we are talking about 3.0, which gives us
(that's how I understand it anyway) a little bit of liberty, as long
as it improves the library.
You are right. We can introduce incompatible changes in 3.0 and in fact
we will introduce many such changes here. I hope it will be for the
better ...
Luc
Sébastien
2011/9/7 Jochen Wiedmann<jochen.wiedm...@gmail.com>:
2011/9/7 Sébastien Brisard<sebastien.bris...@m4x.org>:
Hi,
as noted in MATH-653, these two methods are redundant, and one should
go. Pros and cons are
* toArray() is fairly classical in the Java world
* but getData() is consistent with ArrayRealVector.getDataRef().
Personnaly, my preference goes to keeping toArray(). In order to
maintain consistency, should ArrayRealVector.getDataRef() be renamed
getArrayRef() ?
Another Con; INcompatible change, which should be avoided, if
possible. Redundancy is not a compelling reason for such changes.
--
Capitalism is the astounding belief that the most wickedest of men
will do the most wickedest of things for the greatest good of
everyone.
John Maynard Keynes (http://en.wikiquote.org/wiki/Keynes)
https://linuxcounter.net/user/221257.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
