[concurrency-interest] Re: AtomicInteger and AtomicLong should implement Number
5 Jan 2004 04:32:08 -0000
> Ignoring issues of whether Number should have been an interface,
> and whether all Numbers must be immutable, exactly why do you
> think AtomicInteger and AtomicLong should be Numbers?
> AtomicInteger and AtomicLong are not numeric types, ala Integer,
> Long, Float, BigDecimal etc, but simply utility classes to access
> int or long values in an atomic way.
Speaking only for myself, from my exposure to, I guess 1000s of
class/interface/type names, and a few nearly ubiquitous naming
patterns/conventions, I can imagine someone seeing "AtomicInteger" and
"AtomicLong" and expecting/inferring they are a kind of Integer and
Long, respectively. Since Integer, Long, and their lot are "Numbers",
I think it is natural to imagine that AtomicInteger and AtomicLong are
likely also "Number"s, perhaps they would be "AtomicNumbers".
In a context where there is something called AtomicReference, which
is a reference to an object, I would expect an object which holds
a reference to an object which is an Integer to be either of type
IntegerAtomicReference, or maybe AtomicIntegerReference, perhaps,
similar to "IntegerValue" in the standard Java JDI (JPDA) package.
In "AtomicInteger", my gut reaction is to think "Atomic" is an
adjective, and "Integer" is a noun, since that is how I almost
always see those words, so I can definitely see thinking an
"AtomicInteger" is an Integer which is Atomic, but then again that
seems kind of meaningless to me, and so I guess I would not try to
intuit whatever meaning may be there, and instead I would go to the
docos to figure out what an "AtomicInteger" is.
I feel pretty sure I could figure out what an IntegerAtomicReference
is, or maybe even an IntegerAtomic, figuring "Atomic" when used as a
noun says "an Atomic object contains an object reference which can
be updated atomically", and so an IntegerAtomic object "contains an
Integer object reference which can be updated atomically".