Yeah, I don't really consider this an API change since it will not break anything coded to the 3.1 API currently.
On Sat, Mar 9, 2013 at 10:06 AM, Andrus Adamchik <[email protected]>wrote: > > Cool. Should I remove it in 3.1 and 3.2 both? > > Good question. 3.1 is now "frozen". At the same time "final" removal > doesn't noticeably change the class signature, so I guess we can sneak it > in without breaking our beta promise. > > Andrus > > > On Mar 9, 2013, at 12:01 AM, 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 > > > > 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 > >>>> > >>>> > >> > >> > >
