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 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 > >> > >> > >
