[concurrency-interest] More on: AtomicInteger and AtomicLong should implement Numbe

Shaffer, Darron Darron_Shaffer@stercomm.com
Fri, 9 Jan 2004 10:28:30 -0600

As I see it,  most of what this JSR deals with is "detail" oriented
programming: get this tricky locking situation right.

This discussion is more about programming in the large: how to deal with
this object when I don't know or care to know precisely what it is.  Try to
think about opening up possibilities.

For example, assume a pretty-print utility that is given an object reference
and uses reflection to produce a human readable output of it and all it's
members, recursively.  Probably for debug purposes.

It could work like this:

	For each field,
	    if it implements PrettyPrintable
	        invoke field.prettyPrint()
                else if it implements Collection
                    get an iterator, and recurse over each member.
                else if it implements Number
                    do some sort of numeric formatting
                    invoke field.toString()

The point being, by not grouping all of the "AtomicNumber" classes under
some interface or baseclass they are harder to seperate out in this type of
model.  Number is the obvious existing candidate.  (OK, Number should
probably be an interface named something like "ConvertableToNumber" -- but
we can't fix everything).

Also consider that there may be some use of generics where a class is

	class Foo <T extends Number> { ... }

Are you certain there is no useful case where an AtomicLong would be used

I'm not saying that these particular examples are correct, just that SOMEONE
will want to do SOMETHING along these lines.  Should it be possible?