You could of course extend a list-like collection, so long as it had such a constructor as you described. But in general, if you want to expose the properties via getters, you then have to perform casting (because a collection is only parameterized with a single type). Tuples and possible nesting of them gives you a structured type, where you can mix and match types as you wish. That's the main point. There are also some inefficiencies that come with using list-like structures for relatively small structures.
Not sure I understand your point about reified generics. Why would it matter? The point here is to achieve type safety at compile time, no? Scala's Pair3, Pair4, etc. are kind of ugly to me too, but their presence does not negate a programmer's ability to nest Pair structures the same way I described initially. It's a complementary approach. Alexey ________________________________ From: Reinier Zwitserloot <[email protected]> To: [email protected] Cc: Reinier Zwitserloot <[email protected]> Sent: Fri, February 18, 2011 11:34:55 PM Subject: Re: [The Java Posse] using structured typing to reduce Java boilerplate Well, sure, this comes up boatloads of times when talking to people that have been sniffing the lisp glue for slightly too long. Yes, there's a sense of elegance in being able to define an arbitrary arity stack of generics, and you can do so using Pairs. However, pragmatically speaking, without reification I don't see the point. What possible good will this bring given the constraints of java? In another language with different constructs and semantics this _might_ be worthwhile (though even scala does not have variable-arity generics, and hacking this together with a chain of Pairs was evidently deemed even uglier than including Pair, Pair3, Pair4, all the way up to Pair23. Which is ugly, so, you know, that says something). But, to get back to Alexey's trick, can't you get the same practical effects (of having a sensible hashCode/toString) by simply extending a list-like class with a protected Object... constructor? This strategy will never get you viable toStrings (Assuming you want the field name listed along with the value), and both extending something and having those 'getA()' methods around just ugly up your API. -- 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. -- 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.
