Tor, is it possible to post the NetBeans Pair class?

Agreed though, would be great to have return x,y,z.  Seems easy enough
too, just implement as an array behind the scenes


On Feb 17, 1:42 pm, Tor Norbye <tor.nor...@gmail.com> wrote:
> 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