Indexing access for Lists and Maps considered harmful?

Tom Hawtin Thomas.Hawtin at Sun.COM
Wed Jun 24 04:39:28 PDT 2009


Ted Neward wrote:
> No. I will strongly oppose any effort to "move away from 100% consistency",
> regardless of how many people on this list use a particular feature or if
> it's an area that "almost nobody uses". Languages have to be consistent, or
> developers' faith in that language begins to erode and the language itself
> begins to die.

I think the languages changes in 1.1 blew that away. Wouldn't that Java 
language universe be better is some of the weird conclusions of the 
inner class spec where simply ruled illegal? It took javac years to 
catch up.

Getting back to this feature. Shouldn't `a[b] = c` be a drop in 
replacement for `a.put(b, c)`? Consider code like these:

j2se/share/classes/com/sun/tools/javac/comp/Check.java:

     if (typeMap.put(t.tsym, t) == null) {

j2se/share/classes/java/util/Collections.java:

     synchronized(mutex) {return m.put(key, value);}

Drop in the new syntactical sugar and we have:

     if ((typeMap[t.tsym] = t) == null) {

     synchronized(mutex) {return m[key] = value;}

Oops. (Admittedly a quick grep for ".put(" or ".set(" and "{" only came 
up with about a dozen or so of these examples in j2se.)

So depending upon circumstance there is a choice of two values that the 
feature must return. The only winning move is not to return anything.

There is no need for javac warnings and errors in these cases to be 
cryptic. Personally I'd lint the array pass through assignment case, but 
that could produce too many warnings.

Tom



More information about the coin-dev mailing list