On 19 March 2013 20:45, Oliver Heger <oliver.he...@oliver-heger.de> wrote: > Am 18.03.2013 11:19, schrieb sebb: > >> On 18 March 2013 10:07, Benedikt Ritter <brit...@apache.org> wrote: >>> >>> 2013/3/18 sebb <seb...@gmail.com> >>> >>>> The new utils.mime classes for MIME decoding are mostly >>>> package-protected. >>>> >>>> However, they have public methods (and ctors) which is a bit misleading. >>>> >>>> I think it would make sense to reduce the visibility to package >>>> protected. >>>> >>>> Any objections? >>>> >>> >>> I personally don't align visibility of methods to the defining classes >>> visibility. If you decide to change the classes visibility to public you >>> will have to go though all methods and change method visibility too... >> >> >> Well yes, of course. >> But these classes are specifically for internal use only. >> >> Also I think objects should be created with the minimum visibility >> required. >> If it turns out more visibility is needed, it can be changed without >> causing incompatibility. >> Reducing visibility after release is not so easy. >> > > Sorry, I disagree here. The classes affected are not part of the public API, > so the argument of reducing visibility does not hold.
In which case, all the methods might as well be public in a package-protected class. If the class is later made public, that could cause problems if some of the methods should not have been made public. > OTOH, different visibility of methods is a hint which methods are expected > to be called from outside and which are internal helper methods. Indeed, which is why the helper methods should be private or package protected as appropriate. > Oliver > > > >>> Benedikt >>> >>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> >>> -- >>> http://people.apache.org/~britter/ >>> http://www.systemoutprintln.de/ >>> http://twitter.com/BenediktRitter >>> http://github.com/britter >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
