Re: an array in a hashtable
Chris Uppal wrote:
While I agree that the combination of method overloading and automatic
conversion leads (at least potentially) to confusion, I don't think I'd go so
far as to blame the above example on that. I don't think it would be possible
to achieve the effect of Thomas's masterful indirection without the more
powerful intuition-breaking possibilities of autoboxing.
It would probably be possible to concoct an example which misbehaved as badly
using only the conversions in Java before 1.5, but I think the API would be
obviously artificial. In this case an /existing/, and not obviously crap[*],
API has been broken by autoboxing.
I think somewhere in the interview below Josh talks about Effective Java
(Item 26) needing tightening up with respect to overloading. The old
collections with "Element" everywhere were a bit clumsy. If List was
written now, it would still have Vector's "At"s.
http://media.libsyn.com/media/javapolis/Joshua_Bloch_and_Neal_Gafter_interview.mp3
If you though autoboxing of primitives was a bit unpleasant, you should
see the proposed autoboxing of closures.
JButton button = new JButton("Click here");
void listener(ActionEvent event) {
button.setText("Clicked");
}
button.addActionListener(listener);
button.removeActionListener(listener);
Now is the listener still applied to the button? It might be, or it
might not. The function type is implicitly boxed. Possibly to a new
object each time. As listener removal is based on ==, using a different
wrapper object will not work.
Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/