Indexing access for Lists and Maps considered harmful?

[Ted Neward]

Except that the semantics of "=" (assignment) are chained, such that

a = b = c;

should evaluate to "c", with "a" and "b" now holding the value that "c"
started off with; in other words,

map[a] = map[b] = c;

means that map[b] should return c, and so should map[a].

As much as returning void is the 'safe' choice, consistency with assignment
in other contexts and expression evaluation order argues that it should
return the value of whatever was just put there (c).

Ted Neward | Principal Consultant, ThoughtWorks
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.thoughtworks.com | http://www.tedneward.com

> -----Original Message-----
> From: coin-dev-bounces at openjdk.java.net [mailto:coin-dev-
> bounces at openjdk.java.net] On Behalf Of Reinier Zwitserloot
> Sent: Monday, June 22, 2009 11:19 PM
> To: Joseph D. Darcy
> Cc: coin-dev at openjdk.java.net
> Subject: Re: Indexing access for Lists and Maps considered harmful?
> 
> You realize this is going to be an instant java puzzler, right? I
> thought one of the soft goals of project coin is to attempt to
> sidestep obvious puzzlers.
> 
> I also admit that I cannot come up with any situation where the
> expression:
> 
> thingA[thingB] = thingC;
> 
> evaluating to something that ISNT 'thingC' (or void) is going to be
> the logical, not confusing choice.
> 
> 
> Suggestion: Define this operation to return void regardless of the
> underlying method implementation's actual return value. That way, if
> in the future a solid use case for letting the method invocation
> decide return type and value is found, a change can be made without
> breaking old code. If, on the other hand, there's a clamour for
> letting this expression return 'thingC', that can be added to a future
> version of java as well.
> 
> In other words, picking EITHER "That evaluates to thingC" OR "That
> evaluates to whatever the put method returns" is a choice you must
> make for the rest of the life of the java language. On the other hand,
> picking "That is a statement and not an expression (e.g. evaluates to
> void)" is not a life-long choice; if it ends up being a bad choice,
> you can switch to either alternative later without any pain other than
> filing a purely additive language change.
> 
> 
> The only obvious disadvantage to 'return void' that I can see is that
> its inconsistent with both the current behaviour of the assignment
> operator AND the desugaring idea, whereas the alternatives are
> consistent with one behaviour and inconsistent with the other. Then
> again, with 'returns thingC' and 'returns returntype of put method',
> the inconsistent behaviour is silent, puzzler-esque, and going to
> cause hundreds of people subtle and hard to find bugs, whereas in the
> 'returns void' scenario, there is no confusion at all, as the compiler/
> editor will instantly tell you that the assignment is a statement and
> not an expression.
> 
> 
> I just talked myself into throwing my overwhelming support behind the
> return void choice. Both other choices lead to long bug hunts and
> confusion that can only be solved by experimenting or grabbing the
> JLS, whereas void can't lead to bug hunts and any confusion it
> engenders is instantly assuaged by a compiler hint.
> 
>   --Reinier Zwitserloot
> 
> 
> 
> On 2009/23/06, at 07:46, Joseph D. Darcy wrote:
> 
> > My current preference is to keep a simple desugaring of the indexing
> > operators into method calls.  While collection usage would certainly
> > be a common case, there are probably other to-be-written APIs that
> > would benefit from the translation into method calls.
> >
> > -Joe
> >
> > Reinier Zwitserloot wrote:
> >> I agree that the expression "map[c] = d" returning the OLD value
> >> of  map[c] (e.g. usually null) is unacceptable behaviour, but I
> >> think this  propsoal would fare just fine if this form of operation
> >> is defined to  return void and not 'd', in order to avoid
> >> confusion. There are many  code bases that never use pass-through
> >> assignment, and the workaround  (write it out...) is by definition
> >> not more boilerplate and noise than  what we have now.
> >>
> >>
> >> I do lean slightly to preferring the expression to return 'd', and
> >> not  void, nor 'old mapping of c'.
> >>
> >>  --Reinier Zwitserloot
> >>
> >>
> >>
> >> On 2009/22/06, at 22:40, Lawrence Kesteloot wrote:
> >>
> >>
> >>> On Mon, Jun 22, 2009 at 12:19 PM, Joseph D.
> >>> Darcy<Joe.Darcy at sun.com>  wrote:
> >>>
> >>>> map["a"] = map["b"] = "c";
> >>>>
> >>>> the new value for key "a" would be the old mapping of "b" and not
> >>>> necessarily "c" because a call to the put method returns the old
> >>>> value.
> >>>>
> >>> There is no way that:
> >>>
> >>>   map["b"] = "c"
> >>>
> >>> can return anything other than "c". Returning the old value or
> >>> returning void would violate 40 years of C-based expectations
> >>> (including the identical construct in the STL). It must either
> >>> return
> >>> "c" or not be implemented at all.
> >>>
> >>> Lawrence
> >>>
> >>>
> >>
> >>
> >>
> >