Hi. > > Would you consider implementing a _mutable_ 3D-vector class? > > 3D vectors have been changed from mutable to immutable for both robustness > and efficiency reasons ...
I'm all convinced that immutability makes for cleaner, and safer code. The question is: Can we be sure that programming with immutable "Vector3D" ojects will always be as efficient? Or equivalently, is the constructor as fast as a method call that would modify an existing object? As far as I'm currently concerned, I've changed my source to use "Vector3D" and, for a code that runs for 60 seconds, the difference is indeed irrelevant (around 1 part in 60). So I'm not going to insist :-) > At the end, it appears that for complex applications with several layers, > there are more copies and allocations with mutable objects than with > immutable objects! Of course this is a loose-loose situation ;-) I still wonder whether there are use-cases that could benefit from a "MutableVector3D" (as was suggested in a previous post). > Another point to note is that the generational garbage collectors work > better with really short lived objects. So small immutable instances are > handled quickly and allocation should not be feared. It is efficient now, > see <http://www.ibm.com/developerworks/java/library/j-jtp09275.html>. This shows that allocation in Java is efficient, but does not compare the constructor with another method call. Although... if the object is short-lived, then the JVM could possibly create it on the stack, while re-using an object may mean that it is long-lived (i.e. on the heap) so that a method call would actually be slower! > [...] Thanks for sharing your experience on the benefits of using immutable objects. Best regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
