To summarize Joel Neely's argument:
"I think java should have tuple packing and unpacking exactly as
python has it".
agreed, sort of. We really have to decide if we want java to become a
structural/nominal hybrid language. Right now java is strictly
nominal. BGGA wants to add functional types, which is structural
typing (I don't give you a Comparator, nono, I give you an {Integer,
Integer => int} - that's not nominal typing). Tuples also smack of
structural typing (in a nominally typed world, every tuple would be
granted a name). We can do both - support an 'unpacking' interface, in
the same vein as Iterable, which has the effect that the unpacking
assignment will load each LHS variable with something given by the
appropriate getTupleValues() call that the Unpackable interface
requires you to have.
There's still the issue of generics. Scala solved this by creating 22
tuple classes. I don't think this is an acceptable solution. Pair-wise
generics requires more generics syntax before you can use it, and if
ever you need to make an explicit mention of the generics type, it's a
total horrorshow (Tuple<String, Tuple<Integer, Tuple<List<String>,
Nothing>>> is what you'd actually have to write when all you meant was
a (String, Integer, List<String>) tuple). It seems logical to just add
N-tupled generics parameters, but that's not exactly a simple change
to make.
Python doesn't have this problem because python is not statically
typed - all python's reference types are effectively 'Object' and all
member access is on a runtime lookup basis. (also known as duck
typing).
The easiest solution, but it feels hackish to me, is to auto-generate
the tuple classes.
On Feb 17, 3:32 pm, "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
-~----------~----~----~----~------~----~------~--~---
