Is there an accepted standard equals() implementation for Tuple?
I wrote a Pair class (Tuple2) in my codebase over a year ago and it's
been surprising to see how many people have started using it. We had
to broach the equals() method question last week when we started using
them as keys in a map.
Two questions we asked are
1. Are tuples ordered? Tuples seem ordered to me. ("foo", "bar") is
not equal to ("bar", "foo").
2. Are nulls equal? (null, null) seems equal to (null, null) given
that the type of the tuples are the same... but how can you easily
discover the generic type at runtime?
On Feb 17, 8:35 pm, Casper Bang <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[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.
>
> > > --
> > > 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 [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
-~----------~----~----~----~------~----~------~--~---
