I agree with Tore... Autoboxing is a confusing solution for the legacy
design holes in Java. It mostly obfuscates things. Having said that, I
guess since it is an official language feature now, we should not
prohibit its use in the Cayenne codebase. But making a special effort
to use it throughout the code looks like a waste of time.
Andrus
On Dec 20, 2007, at 4:48 PM, Tore Halset wrote:
On Dec 20, 2007, at 14:35 , Kevin Menard wrote:
On 12/20/07 7:06 AM, "Tore Halset" <[EMAIL PROTECTED]> wrote:
I am currently -1 to autoboxing, but Integer.valueOf(int) should not
be a problem for anyone.
Why is that? I was just about to commit changes that replaces all
of the
explicit unboxing and boxing code with autoboxing. This would
improve code
clarity in various places.
It will make the code smaller, but will the code be clearer? As in
easier to understand?
Autoboxing yields nearly identical bytecode to manual boxing/unboxing
operations. The only time I've found it's problematic is when you
forget
what type you're working with to the point that you really should
be using
the object type or the primitive type natively.
I have been bitten by a couple of situations where I thought my
primitive type was primitive, but in fact had been autoboxed. This
is extra confusing when you have objects that have identical
methods, but with primitive and non primitive arguments. Like
List<Integer>.remove(int) and List<Integer>.remove(Integer) doing
two very different things. It is also a bit confusing when
autoboxing happens when you do not know about it. I do not have that
many good examples, but have googled some discussion around the
subject.
http://episteme.arstechnica.com/eve/forums/a/tpc/f/6330927813/m/867001348831/r/448008648831
http://www.theserverside.com/news/thread.tss?thread_id=27129
Perhaps I can learn to like it over time :) What about you other guys?
- Tore.
