[ 
https://issues.apache.org/jira/browse/MRUNIT-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13429099#comment-13429099
 ] 

Bertrand Dechoux commented on MRUNIT-125:
-----------------------------------------

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

        

Reply via email to