Yes, I understand erasure. But a motivated developer could always concoct some hideous workaround out of type tokens.
On Feb 25, 1:31 pm, Robert Fischer <[email protected]> wrote: > 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 <[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 > > -- > ~~ Robert Fischer. > Grails Training http://GroovyMag.com/training > Smokejumper Consultinghttp://SmokejumperIT.com > Enfranchised Mind Bloghttp://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 [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 -~----------~----~----~----~------~----~------~--~---
