For me a tuple is the equivalent of a struct.
What'd be nice in my book is to be able to unify parameter lists and tuples
and default parameter values.
But not for JAva, I'll let this come to me in Scala instead :)
On Tue, Feb 17, 2009 at 10:52 PM, Ben Schulz <ya...@gmx.net> wrote:
>
> I don't think the proposal is bad, but you still have to define what a
> tuple is. For instance, I really hope this would still be valid code:
>
> Object o = ("", 1); // Object's famous top type semantics*
>
> Anyways, I really think this should go farther than Java The Language,
> but -- similar to Neil Gafter's function types -- tuples should be
> part of Java The Platform.
>
> PS: If you have not already, see Neil's excellent talk on Java The
> Platform:
> http://www.infoq.com/presentations/gafter-jvm-closures
> (The URI suggests it's all about closures, but it's not.)
>
> On 17 Feb., 15:32, "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.
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
