On 12/20/07 9:48 AM, "Tore Halset" wrote:
Why is that? I was just about to commit changes that replaces all
explicit unboxing and boxing code with autoboxing. This would
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
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.
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 ;-)