[
https://issues.apache.org/jira/browse/CLI-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504143
]
Ben Speakmon commented on CLI-21:
---------------------------------
My comment from the mailing list thread:
Implementing clone() properly is a pain and hard to get right. If someone
really needs distinct copies of Option classes (why?!), I'd suggest providing a
copy constructor instead. If compatibility is a really big deal, you could
change clone() to call Object.clone(), which throws an exception. Think of it
as a gentle hint to the user not to use the method anymore -- and the exception
message could also point out the new copy constructor.
> [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]
