On 16 February 2011 10:06, Fabrizio Giudici <[email protected]>wrote:
> On 02/16/2011 08:06 AM, Miroslav Pokorny wrote: > >> Why would anyone want Person to be a Pair<F,Pair<B,Z>> ? >> >> I have got some questions and curiosity about this approach, but not that > specific question. I understand that making a Person a Pair<...> is just an > implementation detail (ok, this brings to the discussion about using the > inheritance for implementing something, and it's one of my questions), so we > shouldn't read it "Person is a kind of Pair". To solve the problem at code > level, one could imagine some compiler trick for generate code implemented > in Lombok. Of course, if you're doing something hidden behind the compiler, > one might question whether there are better implementations than Pair<...> > > So, my first question is: what's the target which we're aiming at? From the > original post I only read: good hashcode/equals, immutability. Are there > other things? If one resorts to Lombok, it could have Guavac to take care of > them in other ways. > > So, I'd exclude that a Lombokized approach to the thing is a valued option > for Pair<...>. At this point, I don't exactly understand "strong typing": of > course, strong typing when using Person is given by the fact that Person > declares Strings and ints. The strong typing coming from Pair<...> seems > only related to the implementation. > > -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici - www.tidalwave.it/people > [email protected] > > It's just an algebraic data type, moderately useful even in the absence of pattern matching (tentatively estimated by Martin Odersky to arrive with Java 11, or thereabouts, so definitely not something worth waiting for with bated breath). The real benefit here is in having a way to avoid Java's boilerplate tax on equals and hashcode. Obviously it's complete nonsense to pair off the last name and age like that outside of a very specific domain (such as a school register) where you'd be interested in perhaps sorting people by their last name and age. A far cleaner solution would be to offer several tuples of varying size to that Person could inherit from Tuple3 (for example). Perhaps even better still, you could use Lombok to give you the same functionality (unless you happen to use IntelliJ) The naming convention is also prone to misunderstanding. Head/Tail smells a lot like a linked list, which perhaps gives the wrong impression, and breaks down quite rapidly when considering larger tuples. I also think that the getters could be dropped entirely in favour of public final fields. This is increasingly being recognized as a best practice when writing immutable objects as it leads to far cleaner code. -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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.
