Possible Tuple library contribution

[GoogleCodeExporter]

Attached is a possible contribution of a tuple library. The library is
consistent with the collections library and is easy to use, e.g.:

<E0,E1> T2<E1,E0> swap(E0 e0, E1 e1) { return t(e1, e0); }

Note generics and ease of construction.

The files are licensed under LGPL; other licences are probably possible, if
necessary (I own the copyright but need to check with my university that an
alternate licence is OK).

Original issue reported on code.google.com by howard.l...@gmail.com on 4 Dec 2007 at 7:36

Attachments:

• Tuples.java
• javadoc.zip

[GoogleCodeExporter]

Thanks for contributing this!  I'll look it over later.

Original comment by jared.l....@gmail.com on 19 Dec 2007 at 9:13

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I apologize for taking so long to examine this.

Google's internal code base has a Pair class, which we didn't include in the 
current
release of Google Collections but may in the future. Your Tuple class expands 
Pair in
two dimensions: supporting tuples of 1-5 elements and including additional 
methods.

While the tuple syntax is really nice in Python, I'm reluctant to add tuples of 
more
than two values to Java. A value class would generally lead to more readable 
code,
even though it requires more keystrokes. 

I'm not sure whether we'd want Pair versions of your map, zip, unzip, and 
rotate2
(swap) methods. The question is how often such methods would be called.

FYI, adding equals(), hashCode(), toString(), and serialization to each class 
would
make them more usable.

Original comment by jared.l....@gmail.com on 25 Feb 2008 at 10:18

[GoogleCodeExporter]

Thanks for your assessment. Taking your points in order:

1. I agree that T2 (Pair) is the most important tuple; but in languages that 
have
tuples I have used bigger ones, hence I went to T5 as a compromise between 2 and
infinity (Scala goes to 22). T1 is needed when processing tuple data 
recursively, it
is a list of one element. Testing if the tuple has size 1 acts as a terminating 
case
for recursive processing, hence T0 isn't needed. However as a matter of style 
people
might like a T0, the empty list.

2. For readability on something exposed publicly I am suggesting that people 
write a
value class by extending one of the tuple classes. This way they have minimum 
typing
and retain all the nice tuple functionality but have both a formally documented 
class
(via Javadoc) and an informally documented class via getter names. This is an
advantage a tuple API has over a built in tuple construct in some languages; 
you can
extend a tuple class (Scala also allows tuple extension). Also, since the 
tuples are
built hierarchically (a T5 is a T4 ... is a T1), recursive algorithms are easy.

3. The methods provided for tuples are a matter of taste, the ones I gave are 
the
ones I find useful and are typical of many languages (e.g. Haskell). Many 
languages
have a map literal, I am using a T2 as a map literal. A method I thought of 
adding,
but didn't, was a multimap constructor from tuples used as multimap literals. 
As I
say, the exact method choice is a matter of taste.

4. equals, hashCode, toString are inherited from AbstractList. The tuples are 
Object
Lists. This is useful because many methods understand Lists or Iterables and 
because
for each understands Iterables.

Original comment by howard.l...@gmail.com on 26 Feb 2008 at 7:09

[GoogleCodeExporter]

Tuples are indeed very useful.  We have our own lgpl tuples available here:

http://openhms.sourceforge.net/common-util/apidocs/index.html

One suggestion i might add for the usefulness of Tuple2 is to make it a 
Map.Entry
(and equals/hashCode compatible), cause there is no default implementation of
Map.Entry in the jdk, and it's very useful to have.

Original comment by jahlborn@gmail.com on 26 Feb 2008 at 10:03

[GoogleCodeExporter]

Unfortunately, it's not possible for a 2-element object to implement both List 
and
Map.Entry because of their conflicting hashCode() requirements:

List.hashCode():
  int hashCode = 1;
  Iterator<E> i = list.iterator();
  while (i.hasNext()) {
      E obj = i.next();
      hashCode = 31*hashCode + (obj==null ? 0 : obj.hashCode());
  }

Map.Entry.hashCode():
     (e.getKey()==null   ? 0 : e.getKey().hashCode()) ^
     (e.getValue()==null ? 0 : e.getValue().hashCode())

If you do need a Map.Entry implementation, Google Collections provides one 
through
com.google.common.collect.Maps.immutableEntry().

Original comment by cpov...@google.com on 26 Feb 2008 at 10:18

[GoogleCodeExporter]

Thanks for the comments.

@Jared: I forgot to mention Serialization in my previous reply to you; yes I 
should
add this.

@jahlborn: Your tuple library is very similar. Either great minds think alike or
fools rarely differ - you decide which :)

@cpov...: It is indeed a pity that the hash code is different. In my own code I 
do
compare T2s with Map.Entrys and I also create maps from T2s using the T2s as map
literals. So I haven't actually needed a T2 to be a Map.Entry. If however 
others have
a need then toMapEntry could be added to T2 and toT2 added to
com.google.common.collect.Maps.immutableEntry's return class (provided that this
class was made public). I also notice 
com.google.common.collect.Maps.containsEntry
and in a similar vein isInMap(Map map) could be added to T2, if there were 
demand.

As a criticism (constructive) of my own code I would add that I extended
AbstractList, unfortunately this comes with the baggage of field modCount. I 
should
really extend AbstractCollection and do the extra work of implementing iterator 
etc.

Original comment by howard.l...@gmail.com on 27 Feb 2008 at 6:47

[GoogleCodeExporter]

@cpov...:  yes, we sacrificed list hashCode compatibility for Map.Entry
compatibility, which we use far more.  in fact, i don't think we've ever used a 
list
as a key in a HashMap.

@howard.lovatt: i prefer the term "wisdomly-challenged".

Original comment by jahlborn@gmail.com on 28 Feb 2008 at 8:25

[GoogleCodeExporter]

While there are some good ideas here, I don't see us including this in the 
Google
Collection Libraries.

There are other ways of making it easier to create value objects, which is the
underlying goal, but I'm not sure which, if any, of those we'll use.

Original comment by jared.l....@gmail.com on 18 Jun 2008 at 9:25

• Changed state: WontFix

[GoogleCodeExporter]

@jared.l.levy: You mentioned future possible inclusion of your Pair class into
google-collections, is it still considered? I'd like to vote for this.

Original comment by earwin@gmail.com on 6 Mar 2009 at 2:56