I definitely agree with this.  This is precisely what I tried to argue
for when I say I want multiple return value support. I do NOT want to
simply add Tuple classes to the library. I want to be able to say
"return x, y, z" from a method for example, and similarly be able to
extract the arguments with a straightforward syntax. The tuple stuff
is just plumbing infrastructure for the compilerS I think (yes, plural
- it would be good to have this be -standard- and not javac specific
such that you can call across languages for these methods.)

-- Tor

On Feb 17, 6:32 am, "joel.neely" <joel.ne...@gmail.com> wrote:
> The discussion of Pair, Triple, Tuple4..Tuple22 etc. makes me wonder
> if this isn't too much of a solution. After writing:
>
>     Tuple<String,Integer> t = someObject.someMethod();
>
> the caller still may need to do something like:
>
>     String s = t._1();  // or "first" or "left" or whatever...
>     int i = t._2(); // or "second" or "right" etc...
>
> Instead of all that, I'm beginning to think that I'd rather have
> simple support for anonymous tuple assignment (or "multiple
> assignment"), which could be done in the compiler. (Yes, I know that
> Al Perlis said "Syntactical sugar causes cancer of the semi-colon.")
> I'm not claiming any great originality here, and will be quite happy
> if someone points me to an existing equivalent proposal already in
> existence.
>
> This proposal has these parts :
>
> 1) LValue lists: Allow a parenthesized, comma-separated list of
> variable references or declarations to appear on the left-hand-side of
> an assignment. For (partial) example:
>
>     (String s, int i) = ...
>
> 2) RValue lists: Allow a parenthesized, comma-separated list of
> expressions to appear on the right-hand-side of an assignment. For
> (remainder of) example:
>
>     ... = (foo.toString().trim(), foo.childCount());
>
> 3) Assignment: Require that the var refs/decls in the lhs list be
> assignment-compatible with the values in the rhs list. So, this is
> valid:
>
>     (String s, int i) = (foo.toString().trim(), foo.childCount());
>
> but this is not:
>
>     (int i, String s) = (foo.toString().trim(), foo.childCount());
>
> 4) Method declaration: Allow a parenthesized, comma-separated list of
> types to appear as the result type of a method definition. For
> example:
>
>     public (String, Integer) getStuff() {...}
>
> 5) Method result: For a method declared as in the previous point,
> require all non-exception termination to be in the form of a return
> statement with a parenthesized, comma-separated list of expressions
> which are compatible with the declared result types (in the sense of
> point 3).
>
>     public (String, Integer) getStuff() {
>         if (this.childCollection == null) throw new
> IllegalStateException("bletch!"); // lame example
>         return (this.toString().trim(), childCollection.size());
>     }
>
> The net effect is that instead of writing something like:
>
>     Tuple<String,Integer> t = someObject.someMethod();
>     String s = t._1();  // or "first" or "left" or whatever...
>     int i = t._2(); // or "second" or "right" etc...
>
> the programmer would simply write:
>
>     (String s, int i) = someObject.getStuff();
>
> and go on about the real work. In addition the multiple-assignment
> idiom has been around for a long time, in many languages, allowing
> such niceties as:
>
>     (a, b) = (b, a);
>
> as a nice way to swap the values of two (mutually-assignment-
> compatible) variables.
>
> I'm not opposed to discussion of other punctuation (instead of "(",
> ")", and ","). I used parens instead of braces above to minimize risk
> of confusion with nested scopes, but there may be other alternatives
> to consider.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to