Indexing access syntax for Lists and Maps
Artur Biesiadowski
abies at adres.pl
Wed Jul 22 14:12:20 PDT 2009
Reinier Zwitserloot wrote:
> I don't understand what you mean. How is the argument "This is going
> to cause subtle, hard to find bugs for the majority of the java
> programming public" confusing implementation with interface?
>
This was probably counterargument for having m[x] = y returning old
value of m[x].
Only bugs "m[x]=y returning y converted to proper type" might cause is
if somebody blindly replaces something(m.put(x,y)) with
something(m[x]=y). To be honest, second construct is a red alert for me
even now (with current array assignment). I do not think that case of
going through old code are replacing it en masse with new [] accessors
is something we should worry about - people would not do it by hand and
if tools are there, they can be smart enough to avoid it. What we should
worry about is new code written - so it contains least surprises.
For me, this means that m[x]=y should behave same way for maps/list as
for arrays.
I expect a lot more common use to start with array and then change it to
use ArrayList. With new accessors, you just have to modify
arguments/variables - rest of the code stays and behaves the same.
About choices 2 and 3 in your case. It is true that most java
programmers would answer RHS unmodified, but they would also probably
have hard time to understand difference between 2 and 3 at all. So, for
our 'Random Java Programmer', choices 2 and 3 are the same - which is a
benefit, because 2 is following 'intuition', while 3 is following JLS
for arrays.
Anyway, if this solution is not chosen, I think that not returning
anything is second best. I would certainly hate returning old value
inside container, or having 'tunnel' solution, as they are completely
against current behavior for arrays.
Regards,
Artur Biesiadowski
More information about the coin-dev
mailing list