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