I could kick myself, it's Neal, not Neil -- sorry. With kind regards Ben
On 17 Feb., 22:52, Ben Schulz <[email protected]> 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" <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
