[ Tim Peierls ] [concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number

Gregg G. Wonderly gregg.wonderly@pobox.com
Wed, 14 Jan 2004 09:22:13 -0600


>How did this get to be such an emotional topic? If you really want to
>use AtomicX instances as keys based on their mutable values instead of
>their identities, no one is stopping you:
>
>   class ComparableAtomicInteger extends AtomicInteger
>                                 implements Comparable<ComparableAtomicInteger
 > {
>       public ComparableAtomicInteger() {}
>       public ComparableAtomicInteger(int value) { super(value); }

What everyone is supposing is that I want to and can add new code to
deal with this issue.  In some cases, sure enough, I can.  In others I can't

I am arguing to preserve the use of the existing classes that already
use Number implementations where equals() and compareTo() have a value based
implementation.

It's emotional because every argument is "but there is so little code to add"
or "you're already gonna change the code".  What I don't see is arguments
that include the whole reusablity, library, existing implementation issue.

The arguments against are emotional.  I am trying to present facts and use
cases that I am familar with.  I threw in the "myopic view" comment because
I don't know how else to classify Dawid's arguments that focus solely on the
"AtomicX can never be used as a Map key" issue.  It is true that there is an
issue with that particular case.  But, AtomicX being mutable does not create
a new problem.  There are plenty of Mutable classes that can be used as Keys
in Maps or that have Comparable implementations etc.  Mutability is thus not
a new issue at all.  People have already learned, or will learn after they
make the mistake that they can't use changing hashCode() classes in a Map
as keys.  This lesson has already been learned by many, including Dawid it
seems.

So, rather than restrict the use of these classes because one use case may be
problematic.  I think we should make the functionality of these classes be in
line with the existing Number instances that are native type containers so
that everyone can use these numeric values as numeric values and not have
to wrap them in some other container to get a value based equals() and
compareTo().

-----
gregg@cytetech.com  (Cyte Technologies Inc)