You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Michael Gentry <mg...@masslight.net> on 2013/03/08 14:22:52 UTC
Cayenne.java
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
Re: Cayenne.java
Posted by Mike Kienenberger <mk...@gmail.com>.
I've done similar things myself. extending unit test Assert classes to
add more convenience methods.
I leave the class name the same, but change the package.
On Fri, Mar 8, 2013 at 10:45 AM, Michael Gentry <mg...@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 <an...@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 <mg...@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
>>
>>
Re: Cayenne.java
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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 <mg...@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 <mg...@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 <mg...@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
> >>>>
> >>>>
> >>
> >>
>
>
Re: Cayenne.java
Posted by Andrus Adamchik <an...@objectstyle.org>.
> 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 <mg...@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 <an...@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 <mg...@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 <mg...@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
>>>>
>>>>
>>
>>
Re: Cayenne.java
Posted by Michael Gentry <mg...@masslight.net>.
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 <gr...@gmail.com>wrote:
> On Fri, Mar 8, 2013 at 10:01 PM, Michael Gentry <mg...@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 <mg...@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 <mg...@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
>
Re: Cayenne.java
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Mar 8, 2013 at 10:01 PM, Michael Gentry <mg...@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 <an...@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 <mg...@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 <mg...@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
Re: Cayenne.java
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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 <mg...@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 <mg...@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
> >>
> >>
>
>
Re: Cayenne.java
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mg...@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 <an...@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 <mg...@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
>>
>>
Re: Cayenne.java
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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 <mg...@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
>
>
Re: Cayenne.java
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mg...@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