[
https://issues.apache.org/jira/browse/PIG-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13286222#comment-13286222
]
Jonathan Coveney commented on PIG-2724:
---------------------------------------
I care not about the AbstractTypeAwareTuple, so I'll axe it. I knew thee well,
AbstractTypeAwareTuple.
As far as the hashCode thing, you are correct of course on the typical equals
contract, but for Tuples, idiomatically they all use compareTo instead. I do
not think that this is an issue. I just think that we should force people to be
thoughtful about compareTo/hashCode and either force both to be overriden, or
neither.
> Make Tuple Iterable
> -------------------
>
> Key: PIG-2724
> URL: https://issues.apache.org/jira/browse/PIG-2724
> Project: Pig
> Issue Type: Improvement
> Reporter: Jonathan Coveney
> Assignee: Jonathan Coveney
> Fix For: 0.11
>
> Attachments: PIG-2724-0.patch, PIG-2724-1.patch, PIG-2724-1.patch,
> PIG-2724-2.patch
>
>
> Seriously, is there a more annoying pattern than the following?
> {code}
> for (int i = 0; i < t.size(); i++) {
> try {
> doStuff(t.get(i));
> } catch (ExecException e) {
> throw new RuntimeException("BUT I THOUGHT PIG WAS SINGLETHREADED", e);
> }
> }
> {code}
> I mean yeah, you can do the following:
> {code}
> for (Object o : t.getAll()) {
> doStuff(o);
> }
> {code}
> But I don't even think that should be necessary. I think the following should
> work:
> {code}
> for (Object o : t) {
> doStuff(o);
> }
> {code}
> It's a shame we can't give a default implementation (I either shake my fist
> that this won't be possible until Java 8 OR that Tuple is an interface and
> not an abstract class). Either way, I even added test! WOAH.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
