Mailing-List: contact dev-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cayenne.apache.org
Received-SPF: pass (nike.apache.org: domain of grobmeier@gmail.com designates
 74.125.82.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAA-upzp-P18iLXSiurFOdnWDVChcvim54t7m5iDAdkXnfLuoFw@mail.gmail.com>
References: 
 <CAA-upzpgpC2BRrfXszpn-jGaOtP2ZLFsyTaCUeYGBFpXarfPpw@mail.gmail.com>
 <BF61D244-1617-4062-8597-8CD4994FF87A@objectstyle.org>
 <CAA-upzqVP4RXs4JJoJdXp2V6xK40KPbtnfWZftJ0vrOcY0-m9g@mail.gmail.com>
 <D291DD7D-AC6C-4D36-9DE2-A15F5ACB121D@objectstyle.org>
 <CAA-upzp-P18iLXSiurFOdnWDVChcvim54t7m5iDAdkXnfLuoFw@mail.gmail.com>
From: Christian Grobmeier <grobmeier@gmail.com>
Date: Sat, 9 Mar 2013 08:02:10 +0100
Message-ID: 
 <CAPFNckhw7Hf-FfsPFzcrcKyC7W8Sq1FZv+XYScSKrzO1KZHk2Q@mail.gmail.com>
Subject: Re: Cayenne.java
To: dev@cayenne.apache.org
Content-Type: text/plain; charset=UTF-8

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