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