Autoboxing

[Kevin Menard <km...@servprise.com>]

On 12/20/07 9:48 AM, "Tore Halset" <ha...@pvv.ntnu.no> wrote:

>> 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?

I certainly think so.  "new Character(b)"; "x.intValue()"; etc.  They all
detract from the core logic.  It'd really help the legibility of the ternary
expressions, IMHO.

I view boxing as a subclass of casting and think it's largely unnecessary.

> 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.

Right, but then the question is are you really using the proper type in the
first place?  Calling intValue() may make things more explicit, but if
you're doing it enough where autoboxing is a problem, maybe you should be
using a primitive type to begin with.
 
> 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?

I can get over it, but I think we employ other practices that can lead to
more serious bugs.  Complex ternary expressions, assignment to method
parameters, assignment to catch block parameters, use of nested postfix
operators, etc.  But that's drawn from my own experience as well.

Let me start using "final" and I'll give up on autoboxing ;-)

-- 
Kevin