cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: Cayenne.java
Date Sat, 09 Mar 2013 15:28:08 GMT
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 <andrus@objectstyle.org>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 <mgentry@masslight.net> 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 <andrus@objectstyle.org
> >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 <mgentry@masslight.net>
> 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 <
> andrus@objectstyle.org
> >>> 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 <mgentry@masslight.net>
> >> 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
> >>>>
> >>>>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message