commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ben Speakmon" <bspeak...@apache.org>
Subject Re: [VOTE] Release CLI 1.1
Date Wed, 13 Jun 2007 05:17:27 GMT
>
>
> It is a minor, rather than bugfix. So I think it's fair to say "Please
> recompile". However, also good to keep backwards compat when it's not
> too painful.


Seeing how I'm about to go down a similar road with commons-email... I'm
okay with requiring a recompile as long as you're not requiring drastic
changes in the client source code.

> 1) Why not deprecate the public fields in HelpFormatter rather than
> > making them private?
>
> I think it's a simple enough change for people to adjust to this one
> if they discover they've used the public fields. So I'd like to be
> bold on this one and not put the public fields back in.


Again, works for me as long as it's not onerous.

Agreed. It's a pain for someone if they've actually used the clone().
> I don't see any great needs to clone options, however someone did
> report a bug with it so that would imply that someone wanted to clone.


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.

I think this was a recent change that Brian and I made (need to
> check). That method should not, not, not, be called by a user. Option
> classes are immutable-ish, but behind the scenes the code mutates
> them. So definitely want to break people who are using this.


+1.

My general subscription is that I want to break it if it's bug
> related, and deprecate it if the removal is just policy or trivial
> (ie: renaming, package moving etc). We do need to sort out the clone
> one, others I think can stay (consensus pending).


Concur -- if it's broken, break it; don't wallpaper over it, because some
poor sod *will* put his head through it eventually.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message