Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka >> mail # dev >> Coding convention: tuples vs case classes


Copy link to this message
-
Coding convention: tuples vs case classes
In KAFKA-391 I tried switching from (topic, partition) tuples to a
TopicPartition case class in the producer/fetch request handling code. I
think it helped quite a bit in terms of code clarity and access from
java-api's. There are still lots of places where we have this:

https://gist.github.com/3718883 (this is after the edits to the request
handling code and does not include other tuples that may be better written
as case classes)

This book [1] has a reasonable guideline (paraphrased): ".. tuples are
almost too easy to use. Tuples are great when you combine data that has no
meaning beyond an A and a B. However, whenever the combination has some
meaning, or you want to add methods to the combination, it is better to go
ahead and create a class... It makes your intentions explicit, which both
clears up the code for human readers and gives the compiler and language
opportunities to help you catch mistakes."

I think we generally intend to follow the above but inadvertently go with
tuples which subsequently spread all over. If there's no objection I can
add the above to our coding convention page.

Thanks,

Joel

[1] http://www.artima.com/shop/programming_in_scala_2ed
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB