Comments on: Dangerous new Language Features: Indexing access syntax for Lists and Maps

By: Frits Jalvingh

Frits Jalvingh — Fri, 10 Jul 2009 12:05:14 +0000

All of this is kind of nonsense. Of course the “contract” of the assignment operation (returning the assigned value) may not change (that point is validly made) – and it is trivial for the compiler to make that so.

This discussion wrongly assumes that the compiler /must/ use the return value of a put as the “result” of the assignment which is nonsense; it can easily generate trivial code to drop (pop) the result of the put and use it’s second parameter as the “return value”. Using another “method” in whatever map is just nonsense and unnecessary: this requires only a few extra bytecode instrutions to be emitted (a dup and a pop, gee).

By: Shams

Shams — Tue, 23 Jun 2009 13:54:30 +0000

The mailing list at Project Coin (http://openjdk.java.net/projects/coin/) would be a nice place to discuss too.

By: Sebastian Mueller

Sebastian Mueller — Tue, 23 Jun 2009 12:19:09 +0000

@Maarten: I saw the proposal and I clearly object to that part of it. it should be rewritten like this, IMHO:

m2[l1[2]] = m2[m1[1]] = 4; // same as HelperClass.assignmentOperator(m2, l1.get(2), HelperClass.assignmentOperator(m2, m1.get(1), 4));

And HelperClass.assignmentOperator should be implemeted as shown earlier to return the assigned value unconditionally. (Of course the compiler could directly inline the code from HelperClass, but at least conceptually it should be done like this.)

I don’t think the the getter should be invoked so that the map gets a chance to “replace” the value as proposed by javer. I think the result should be the same if you do:
m2[l1[2]] = m2[m1[1]] = 4;
and
m2[m1[1]] = 4;
m2[l1[2]] = 4;

(note the order) – the right-most assignment should be “executed” first.

If a developer needs the different (and less common, IMHO) behavior, she can use the slightly more verbose syntax using the put/get methods.

By: Maarten Winkels

Maarten Winkels — Tue, 23 Jun 2009 10:45:47 +0000

@Sebastian: I completely agree. The current proposal, however, states:

  m2[l1[2]] = m2[m1[1]] = 4; // same as m2.put(l1.get(2), m2.put(m1.get(1), 4));

(see ADVANCED EXAMPLE section)

By: javer

javer — Tue, 23 Jun 2009 10:32:40 +0000

better way is to use special interface for “indexed” access – this will work for all collections and lists and all other stuff.

By: javer

javer — Tue, 23 Jun 2009 10:08:40 +0000

residence["Maarten Winkels"] = residence["Koningin Beatrix"] = “Palace”;

i think better is to do this way:
residence.put(”Koningin Beatrix”, “Palace”);
residence.put(”Maarten Winkels”, residence.get(”Koningin Beatrix”));

because correct order is from left to right, and semantic of
residence["Maarten Winkels"] = residence["Koningin Beatrix"];

have to be transformed into:
residence.put(”Maarten Winkels”, residence.get(”Koningin Beatrix”));

By: javer

javer — Tue, 23 Jun 2009 10:04:03 +0000

how should work int x, y;
x = y = 5;
print(x);
print(y);

what is the result?

let’s change x and y to List.

List x = …;
List y = …;

x[0] = y[0] = 5;

This MUST work same way as x = y = 5; And use same semantic.

For my it does not matter will it use put method or any other.
residence["Maarten Winkels"] = residence["Koningin Beatrix"] = “Palace”;

should workas:
residence.put(”Koningin Beatrix”, “Palace”);
residence.put(”Maarten Winkels”, “Palace”);

By: Sebastian Mueller

Sebastian Mueller — Tue, 23 Jun 2009 07:46:44 +0000

Who says that the assignment operator has to directly map to the put/set methods? Why not map to these methods and nevertheless make the expression (that’s what it is conceptually, its not a method call) evaluate to the assigned value. This can be done using the static method I outlined above.
In Java an assignment expression always evaluates to the assigned value. A method may return whatever it wants. If the language supports the assignment expression as a convenience method for the put/set methods, it should use the assignment semantics and evaluate to the value being assigned.
This does not make it any more complicated: With the current proposal the developers needs to know that directly the method maps to the put method *and* returns the return value of the put method. Using the other proposal the developer needs to know that it maps to the put method (which is rather obvious) and behaves like the assignment operator does everywhere else in Java (which should be obvious).
If a developer comes across this kind of code without knowing that it maps to the put method, my guess would be that she takes the “assignment-expression-evaluates-to-assigned-value” part for granted, because that is what they *already know*.
Also think about (hand-)refactoring consequences if change the type of the variable from array to arraylist and forget to adjust the double assignments.

By: RFletch

RFletch — Tue, 23 Jun 2009 06:47:38 +0000

Noone is ever going to use it in the double assignment case. In fact, I’d be for removing double assignment and getting this feature if people are worried about it given how infrequently double assignment is actually useful to me rather than decoration.

By: Kaj

Kaj — Tue, 23 Jun 2009 06:44:00 +0000

I don’t see this a huge problem. There will always be developers that write code that is hard to understand, and I really really doubt that you often will see code like:

residence["Maarten Winkels"] = residence["Koningin Beatrix"] = “Palace”;

(And I actually read that correct when I read it, since I knew that put returns the previous value). Boxing/Unboxing is far more dangerous.