I'd like to make a slight clarification here. The pairing off of
fields is irrelevant. Only consistency of pairing off of those fields
is important. By wrapping a nesting of tuples into a named class like
Person and specifying which portions of the tuples mean what by
defining accessor methods accordingly, we reduce ambiguity. If I
wanted to define a data structure representing a person's first and
last name only, I could of course say Pair<String, String>, but I
wouldn't know which was which. However, this will make it
unambiguous:
public class FullName extends Pair<String, String>
{
public FullName(String first, String last) { super(first, last); }
public String getFirst() { return head; }
public String getLast() { return tail; }
}
As to the question of sorting -- note that Pair has no natural order.
I am a bigger proponent of supplying custom Comparator implementations
for ordered collections:
Comparator<Person> ageComparator = new Comparator<Person>()
{
public int compare(Person p1, Person p2) { return p1.getAge() -
p2.getAge(); }
};
Comparator<Person> ageLastComparator = new Comparator<Person>()
{
public int compare(Person p1, Person p2)
{
int comparison = p1.getAge() - p2.getAge();
if(comparison == 0)
comparison = p1.getLast().compareTo(p2.getLast());
return comparison;
}
};
On Feb 16, 5:36 am, Kevin Wright <[email protected]> wrote:
> 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.
