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 14:13:08 GMT
I did a quick grep through 3.1 and found these for consideration, too:

HessianUtil.java [1]
DataObjectUtils.java [2]
JoinTreeNode.java [3]
FlattenedArcKey.java [3]
PropertyComparator.java [1]
ConversionUtil.java [1]
LinkedDeque.java [1]

[1] Yes
[2] Yes, even though deprecated.
[3] Perhaps, didn't search for usage patterns.

mrg



On Sat, Mar 9, 2013 at 2:02 AM, Christian Grobmeier <grobmeier@gmail.com>wrote:

> On Fri, Mar 8, 2013 at 10:01 PM, 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
>
> 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 <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
> >> >>
> >> >>
> >>
> >>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>

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