[
https://issues.apache.org/jira/browse/MRUNIT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13429099#comment-13429099
]
Bertrand Dechoux edited comment on MRUNIT-125 at 8/6/12 12:00 PM:
------------------------------------------------------------------
> Good work Bertrand. A question though - the fluent methods work well now in
> the base classes, so why do we still need them in the individual drivers? If
> we don't delete them, we've got more duplication than when we started! I
> think these can be safely removed now.
That's clearly an error. I did remove them for the first patch, maybe I missed
a few of them when I updated the version of my working copy. Would that make
sense to you if I add a final keyword to all of these methods? It would help me
and I don't see any reasons for not doing so. Worst case, we could remove the
final keyword later if needed and it shouldn't impact anybody.
Anyway, I cannot check now but if I do need to change my patch, how we do it? I
submit a patch on the patch? (Brock did commit it.)
> Also - please be careful not to lose the @Deprecated markers that James
> introduced in MRUNIT-64, and watch out for javadoc warnings following the
> code move.
I clearly saw them in the patch of MRUNIT-64 but not in the trunk... I will
check again.
was (Author: bdechoux):
Good work Bertrand. A question though - the fluent methods work well now in
the base classes, so why do we still need them in the individual drivers? If we
don't delete them, we've got more duplication than when we started! I think
these can be safely removed now.
> That's clearly an error. I did remove them for the first patch, maybe I
> missed a few of them when I updated the version of my working copy. Would
> that make sense to you if I add a final keyword to all of these methods? It
> would help me and I don't see any reasons for not doing so. Worst case, we
> could remove the final keyword later if needed and it shouldn't impact
> anybody.
> Anyway, I cannot check now but if I do need to change my patch, how we do
> it? I submit a patch on the patch? (Brock did commit it.)
Also - please be careful not to lose the @Deprecated markers that James
introduced in MRUNIT-64, and watch out for javadoc warnings following the code
move.
> I clearly saw them in the patch of MRUNIT-64 but not in the trunk... I will
> check again.
> reduce duplicate code related to fluent methods with generics
> -------------------------------------------------------------
>
> Key: MRUNIT-125
> URL: https://issues.apache.org/jira/browse/MRUNIT-125
> Project: MRUnit
> Issue Type: Improvement
> Reporter: Jim Donofrio
> Assignee: Bertrand Dechoux
> Fix For: 1.0.0
>
> Attachments: mrunit-125-patch.diff, mrunit-125-spoiler.diff,
> mrunit-125.diff
>
>
> There is a lot of duplicate code in order to provide fluent style with
> methods. We could reduce the duplicate code with generics by adding an
> unbound type parameter T to TestDriver and then all the fluent methods could
> go in TestDriver but return type T. The base classes, MapDriverBase etc,
> would just pass the T on so you would have:
> public abstract class TestDriver<K1, V1, K2, V2, T>
> public abstract class MapDriverBase<K1, V1, K2, V2, T> extends TestDriver<K1,
> V1, K2, V2, T>
> public class MapDriver<K1, V1, K2, V2> extends MapDriverBase<K1, V1, K2, V2,
> MapDriver<K1, V1, K2, V2>>
--
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
