The generic type is gone, and there's no way to get a handle on it, either at
runtime or compile
time. http://enfranchisedmind.com/blog/2007/05/17/the-generics-controversy/
Tuple equality is basically the same as List equality in Java due to type
erasure.
~~ Robert.
Hamlet D'Arcy wrote:
> 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 <casper.b...@gmail.com> 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 <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
> >
>
--
~~ Robert Fischer.
Grails Training http://GroovyMag.com/training
Smokejumper Consulting http://SmokejumperIT.com
Enfranchised Mind Blog http://EnfranchisedMind.com/blog
Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
