On Fri, Mar 8, 2013 at 10:01 PM, Michael Gentry <[email protected]> wrote: > Cool. Should I remove it in 3.1 and 3.2 both? > > BTW, I was curious how other utility packages worked and Apache Commons > doesn't do final, either: > > http://commons.apache.org/proper/commons-lang//apidocs/org/apache/commons/lang3/StringUtils.html
When I remember correctly there was a discussion on Commons on final before ages and i think the outcome was final classes are usually not needed and should be avoided. Personally I think final is not so nice, because you can't know what people do. If there are not really good reasons for a final class, like extending String would probably mess up the string constant pool or so, I prefer to avoid it. If it is only there because of compiler optimization, I think modern compilers can optimize a static method only class without the final modifier - but I have no reference to prove it. Cheers Christian > Thanks, > > mrg > > > On Fri, Mar 8, 2013 at 2:50 PM, Andrus Adamchik <[email protected]>wrote: > >> BTW, even though this won't be my coding style to extend o.a.c.Cayenne, I >> have nothing against removing "final" from it. >> >> >> On Mar 8, 2013, at 6:45 PM, Michael Gentry <[email protected]> wrote: >> > Well, they "inherit" in the ability to call them. For example, if you >> had: >> > >> > public class CayenneUtil extends Cayenne >> > { >> > // Many more static utility methods here >> > } >> > >> > You could still then still call: >> > >> > CayenneUtil.intPKForObject(artist) >> > >> > This will call the "inherited" Cayenne.java method, plus you can call >> your >> > project-defined utilities with the same class. I see this as being more >> > user-friendly. I'm not talking about redefining the static methods, but >> > compositing new static methods in a subclass for simplification of >> calling >> > Cayenne-supplied utility methods and project-supplied utility methods. >> > >> > Thanks, >> > >> > mrg >> > >> > >> > On Fri, Mar 8, 2013 at 10:27 AM, Andrus Adamchik <[email protected] >> >wrote: >> > >> >> Yeah. All its methods are static. There's no static inheritance in Java >> >> (unlike in say Objective C, you can't truly redefine a static method). >> So >> >> there's no instance behavior to inherit. In my mind this is a good >> reason >> >> to not ever want to subclass "Cayenne". >> >> >> >> Of course API style often comes down to personal preferences :) >> >> >> >> Andrus >> >> >> >> On Mar 8, 2013, at 4:22 PM, Michael Gentry <[email protected]> >> wrote: >> >> >> >>> I was just looking at Cayenne.java introduced in 3.1 and noticed that >> it >> >> is >> >>> declared to be a final class. Is there any reason for this? I can >> quite >> >>> easily see people wanting to subclass it to add their own utility >> methods >> >>> which would make it easier for all those utilities to be grouped >> together >> >>> in one bigger class rather than spread out over several classes (from >> an >> >>> end-user's perspective of having to deal with different imports to >> access >> >>> the utilities -- obviously there would still be multiple classes, it >> >> would >> >>> just be better hidden). >> >>> >> >>> Thanks, >> >>> >> >>> mrg >> >> >> >> >> >> -- http://www.grobmeier.de https://www.timeandbill.de
