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 Fri, 08 Mar 2013 21:01:44 GMT
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