Agreed. The topic was taken for a spin on the Fan discussion board
before Christmas where it boiled down to the problem of how to keep
such power confined to internal API's only, where it belongs:
http://www.fandev.org/sidewalk/topic/399
I always wondered if type inference across a (final) method dispatch
couldn't solve the problem in a more OO fashion, but for that to be
possible we'd need automatic properties so there goes that idea.
/Casper
On 18 Feb., 01:33, Michael Neale <michael.ne...@gmail.com> wrote:
> yes I have recently lost all interest in the java language - it seems
> futile to spend effort talking about changes - the amount of effort
> required to effect a change is mammoth. So start fresh. It feels
> good !
>
> On Feb 18, 8:56 am, Viktor Klang <viktor.kl...@gmail.com> wrote:
>
> > 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
-~----------~----~----~----~------~----~------~--~---
