[ 
https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504139
 ] 

Brian Egge commented on CLI-21:
-------------------------------

Properly supporting Cloneable is fairly trivial.  Previously I submitted a 
patch which includes a proper implementation and test case. See:

https://issues.apache.org/jira/secure/attachment/12358085/Cloneable.patch

There's some other code in the patch which does not need to be included.  In 
practice usually the CLI library is only invoked once at startup, so it doesn't 
matter that some classes aren't quite immutable.  However, in unit testing, the 
options may be reused.  

I have some code which looks like this:

abstract class CommandLine {
  protected static final Option URL = new Option("u", "url", true, "url");
}

I'll then share this option in various subclasses.  In my unit tests, it would 
be best if I don't alter the original static option.  In this situation having 
a clone option might be helpful.  The better solution would probably just be 
not to make it static and forget about cloning altogether.

I'm not opposed to removing clone, but I don't see a strong enough reason here 
to break compatibility.

> [cli] clone method in Option should use super.clone()
> -----------------------------------------------------
>
>                 Key: CLI-21
>                 URL: https://issues.apache.org/jira/browse/CLI-21
>             Project: Commons CLI
>          Issue Type: Bug
>          Components: CLI-1.x
>    Affects Versions: 1.0
>         Environment: Operating System: other
> Platform: Other
>            Reporter: Nathan McDonald
>             Fix For: 1.1
>
>
> In
> org.apache.commons.cli.Option
> public method clone is implemented by creating a new instance through one of 
> the class Constructors, and then assigning values as required through the 
> setter methods.
> This means that any subclasses of the Option class will not return a true 
> clone, but a new Option instance instead.
> A proper implementation of clone should use super.clone() to create a new 
> instance, rather than calling the class constructor.  This allows shallows 
> clones to propogate correctly down to subclasses.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to