Re: Newbie: cloning a Number
Andreas Leitgeb wrote:
Patricia Shanahan <pats@acm.org> wrote:
I'm still surprised that it is not provided, even just for completness
(as well as for String, but there you have a copy ctor).
Is clone evil?
I don't understand clone's attraction for a class such as String, a
final class with immutable instances.
I think, String was just used for comparision:
It *can* be indirectly cloned.
But that is just because it is not abstract (nor an interface).
Number is not final, and thus not guaranteed immutable.
So I do understand the wish for Number being cloneable.
Specify verbally in the docs that only either immutable,
or unshared instances shall be passed to your method.
In Number's case the original API classes extending it all did have
immutable instances, but there are two problems with depending on that:
1. As you say, Number is not final, so there could be implementations
outside the API.
2. The new AtomicInteger and AtomicLong are definitely not immutable,
but extend Number.
AtomicInt and AtomicLong do not themselves implement Cloneable. That
does make some sense. By definition, they are intended for shared data
without explicit synchronization. Making a copy is rather problematic,
because another thread could be changing the value as you copy.
Maybe it's time to look at the problem one level up? Why is the Number
copy being made? Does it make sense for all Number implementations?
Patricia