commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon (JIRA)" <>
Subject [jira] Commented: (CLI-21) [cli] clone method in Option should use super.clone()
Date Wed, 13 Jun 2007 07:03:01 GMT


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:
>             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:
For additional commands, e-mail:

View raw message