commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: [cli] Fixing backwards compatabilities
Date Wed, 13 Jun 2007 18:59:47 GMT
On 6/13/07, Henri Yandell <flamefew@gmail.com> wrote:

> 3) Deal with the public boolean addValue->package private void addValue.
>
> Current thinking is to move the new one to a new name and have the old
> method throw an UnsupportedOperationException.
>
> One other thought - should the package private new method be protected
> instead? It seems to make sense that if Parsers in CLI had to talk to
> it, then ones outside CLI might too. It's the abstract class that
> talks to it, so people extending that wouldn't have a problem. So,
> protected?

Of course, that's crap too. People extending Parser would have to
extend Option too, which would suck. The conversation, lost to history
and not recorded in svn log, goes much like this I suspect:

* People shouldn't use addValue unless they're a parser. We should restrict it.
* Our Parser needs it.
* Package private then.
* Other Parsers might need it.
* Arrgh. Crappy API. Let's make a CLI2.

So ignore the protected suggestion.

Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message