You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2013/01/10 21:15:12 UTC
Re: [v2] final keyword
Since there is no negative feedback, I'll add final keywords.
Gary
On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com> wrote:
> Hi All:
>
> The final keyword in trunk: sometimes it is used, sometimes not. I propose
> we use it all over consistently.
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [v2] final keyword
Posted by Tushar Kapila <tg...@gmail.com>.
True but does that make a difference for strings and ints which are
most used with final ?
On 1/15/13, Joern Huxhorn <jh...@googlemail.com> wrote:
> But const in C++ is different from final in Java.
> const means that the whole object state is immutable while final does only
> mean that the reference (not the referenced objects state) is immutable.
>
> Joern
>
>
> On 14.01.2013, at 21:27, Gary Gregory <ga...@gmail.com> wrote:
>
>> Coincidentally, here's a read about Doom 3's source code that mentions
>> C++'s const:
>> http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>>
>> See also John Carmac's comments at the end.
>>
>> Gary
>>
>>
>> On Fri, Jan 11, 2013 at 4:10 AM, Tushar Kapila <tg...@gmail.com> wrote:
>> +1 final and thank you for interesting reads. This thread and others.
>>
>> On 1/11/13, Gary Gregory <ga...@gmail.com> wrote:
>> > On Jan 10, 2013, at 19:55, Ralph Goers <ra...@dslextreme.com>
>> > wrote:
>> >
>> >
>> > On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
>> >
>> >
>> > It all depends on what "..." contains doesn't it? If it's a simple
>> > one-liner-single-method-call-with-no-args, the "final" may seem
>> > overkill,
>> > but it is more complex it is not IMO. This is all about communicating
>> > intent. I prefer to use final consistently than making a judgement call
>> > on
>> > whether this or that declaration benefits. Either the value is constant
>> > or
>> > it is not.
>> >
>> >
>> > Yes, it is true that what "..." contains matters. I would argue that in
>> > the
>> > specific case of LogManager that within the static block the
>> > declarations
>> > of managerProps, factoryClass and cl are worthy of being declared
>> > final.
>> > All the rest are unnecessary. However, it is just a matter of opinion
>> > and
>> > not something worth fighting about (but definitely worth discussing
>> > just
>> > because it is interesting).
>> >
>> >
>> > Yes, interesting chat! :)
>> >
>> > Gary
>> >
>> >
>> >
>> >
>> >>
>> >> While I have no great objection to this I find it to be of minimal
>> >> value.
>> >> In general, methods and blocks should be fairly short so the
>> >> "clarity"
>> >> declaring these variable final provides isn't of much value to me.
>> >>
>> >
>> > Great point, "clarity" yes, but clarity *of intent* is my goal, which
>> > is
>> > different than clarity of coding in the fewest amount of characters a la
>> > C.
>> > I'm no great believer of "self-documenting" code, but using final helps
>> > say
>> > "this name is not a variable, it is a constant".
>> >
>> >
>> > Interesting argument. But I would argue that none of the local
>> > variables
>> > marked as final (even the variables I noted above) are actually
>> > "constants". Rather, they are variables whose values do not happen to
>> > change within the block of code they occur in. From that point of
>> > view,
>> > I'm not really sure I care. If I need to come along tomorrow and cause
>> > the
>> > value to change for whatever reason I'm going to do it. Since that
>> > would
>> > happen within the scope of a few lines of code having the final keyword
>> > doesn't help me much.
>> >
>> > Ralph
>> >
>>
>> --
>> Sent from my mobile device
>>
>> Regards
>> Tushar Kapila
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Sent from my mobile device
Regards
Tushar Kapila
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Joern Huxhorn <jh...@googlemail.com>.
But const in C++ is different from final in Java.
const means that the whole object state is immutable while final does only mean that the reference (not the referenced objects state) is immutable.
Joern
On 14.01.2013, at 21:27, Gary Gregory <ga...@gmail.com> wrote:
> Coincidentally, here's a read about Doom 3's source code that mentions C++'s const: http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
>
> See also John Carmac's comments at the end.
>
> Gary
>
>
> On Fri, Jan 11, 2013 at 4:10 AM, Tushar Kapila <tg...@gmail.com> wrote:
> +1 final and thank you for interesting reads. This thread and others.
>
> On 1/11/13, Gary Gregory <ga...@gmail.com> wrote:
> > On Jan 10, 2013, at 19:55, Ralph Goers <ra...@dslextreme.com> wrote:
> >
> >
> > On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
> >
> >
> > It all depends on what "..." contains doesn't it? If it's a simple
> > one-liner-single-method-call-with-no-args, the "final" may seem overkill,
> > but it is more complex it is not IMO. This is all about communicating
> > intent. I prefer to use final consistently than making a judgement call on
> > whether this or that declaration benefits. Either the value is constant or
> > it is not.
> >
> >
> > Yes, it is true that what "..." contains matters. I would argue that in the
> > specific case of LogManager that within the static block the declarations
> > of managerProps, factoryClass and cl are worthy of being declared final.
> > All the rest are unnecessary. However, it is just a matter of opinion and
> > not something worth fighting about (but definitely worth discussing just
> > because it is interesting).
> >
> >
> > Yes, interesting chat! :)
> >
> > Gary
> >
> >
> >
> >
> >>
> >> While I have no great objection to this I find it to be of minimal value.
> >> In general, methods and blocks should be fairly short so the "clarity"
> >> declaring these variable final provides isn't of much value to me.
> >>
> >
> > Great point, "clarity" yes, but clarity *of intent* is my goal, which is
> > different than clarity of coding in the fewest amount of characters a la C.
> > I'm no great believer of "self-documenting" code, but using final helps say
> > "this name is not a variable, it is a constant".
> >
> >
> > Interesting argument. But I would argue that none of the local variables
> > marked as final (even the variables I noted above) are actually
> > "constants". Rather, they are variables whose values do not happen to
> > change within the block of code they occur in. From that point of view,
> > I'm not really sure I care. If I need to come along tomorrow and cause the
> > value to change for whatever reason I'm going to do it. Since that would
> > happen within the scope of a few lines of code having the final keyword
> > doesn't help me much.
> >
> > Ralph
> >
>
> --
> Sent from my mobile device
>
> Regards
> Tushar Kapila
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Gary Gregory <ga...@gmail.com>.
Coincidentally, here's a read about Doom 3's source code that mentions
C++'s const:
http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code?post=56177550
See also John Carmac's comments at the end.
Gary
On Fri, Jan 11, 2013 at 4:10 AM, Tushar Kapila <tg...@gmail.com> wrote:
> +1 final and thank you for interesting reads. This thread and others.
>
> On 1/11/13, Gary Gregory <ga...@gmail.com> wrote:
> > On Jan 10, 2013, at 19:55, Ralph Goers <ra...@dslextreme.com>
> wrote:
> >
> >
> > On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
> >
> >
> > It all depends on what "..." contains doesn't it? If it's a simple
> > one-liner-single-method-call-with-no-args, the "final" may seem overkill,
> > but it is more complex it is not IMO. This is all about communicating
> > intent. I prefer to use final consistently than making a judgement call
> on
> > whether this or that declaration benefits. Either the value is constant
> or
> > it is not.
> >
> >
> > Yes, it is true that what "..." contains matters. I would argue that in
> the
> > specific case of LogManager that within the static block the declarations
> > of managerProps, factoryClass and cl are worthy of being declared final.
> > All the rest are unnecessary. However, it is just a matter of opinion
> and
> > not something worth fighting about (but definitely worth discussing just
> > because it is interesting).
> >
> >
> > Yes, interesting chat! :)
> >
> > Gary
> >
> >
> >
> >
> >>
> >> While I have no great objection to this I find it to be of minimal
> value.
> >> In general, methods and blocks should be fairly short so the "clarity"
> >> declaring these variable final provides isn't of much value to me.
> >>
> >
> > Great point, "clarity" yes, but clarity *of intent* is my goal, which is
> > different than clarity of coding in the fewest amount of characters a la
> C.
> > I'm no great believer of "self-documenting" code, but using final helps
> say
> > "this name is not a variable, it is a constant".
> >
> >
> > Interesting argument. But I would argue that none of the local variables
> > marked as final (even the variables I noted above) are actually
> > "constants". Rather, they are variables whose values do not happen to
> > change within the block of code they occur in. From that point of view,
> > I'm not really sure I care. If I need to come along tomorrow and cause
> the
> > value to change for whatever reason I'm going to do it. Since that would
> > happen within the scope of a few lines of code having the final keyword
> > doesn't help me much.
> >
> > Ralph
> >
>
> --
> Sent from my mobile device
>
> Regards
> Tushar Kapila
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [v2] final keyword
Posted by Tushar Kapila <tg...@gmail.com>.
+1 final and thank you for interesting reads. This thread and others.
On 1/11/13, Gary Gregory <ga...@gmail.com> wrote:
> On Jan 10, 2013, at 19:55, Ralph Goers <ra...@dslextreme.com> wrote:
>
>
> On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
>
>
> It all depends on what "..." contains doesn't it? If it's a simple
> one-liner-single-method-call-with-no-args, the "final" may seem overkill,
> but it is more complex it is not IMO. This is all about communicating
> intent. I prefer to use final consistently than making a judgement call on
> whether this or that declaration benefits. Either the value is constant or
> it is not.
>
>
> Yes, it is true that what "..." contains matters. I would argue that in the
> specific case of LogManager that within the static block the declarations
> of managerProps, factoryClass and cl are worthy of being declared final.
> All the rest are unnecessary. However, it is just a matter of opinion and
> not something worth fighting about (but definitely worth discussing just
> because it is interesting).
>
>
> Yes, interesting chat! :)
>
> Gary
>
>
>
>
>>
>> While I have no great objection to this I find it to be of minimal value.
>> In general, methods and blocks should be fairly short so the "clarity"
>> declaring these variable final provides isn't of much value to me.
>>
>
> Great point, "clarity" yes, but clarity *of intent* is my goal, which is
> different than clarity of coding in the fewest amount of characters a la C.
> I'm no great believer of "self-documenting" code, but using final helps say
> "this name is not a variable, it is a constant".
>
>
> Interesting argument. But I would argue that none of the local variables
> marked as final (even the variables I noted above) are actually
> "constants". Rather, they are variables whose values do not happen to
> change within the block of code they occur in. From that point of view,
> I'm not really sure I care. If I need to come along tomorrow and cause the
> value to change for whatever reason I'm going to do it. Since that would
> happen within the scope of a few lines of code having the final keyword
> doesn't help me much.
>
> Ralph
>
--
Sent from my mobile device
Regards
Tushar Kapila
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Gary Gregory <ga...@gmail.com>.
On Jan 10, 2013, at 19:55, Ralph Goers <ra...@dslextreme.com> wrote:
On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
It all depends on what "..." contains doesn't it? If it's a simple
one-liner-single-method-call-with-no-args, the "final" may seem overkill,
but it is more complex it is not IMO. This is all about communicating
intent. I prefer to use final consistently than making a judgement call on
whether this or that declaration benefits. Either the value is constant or
it is not.
Yes, it is true that what "..." contains matters. I would argue that in the
specific case of LogManager that within the static block the declarations
of managerProps, factoryClass and cl are worthy of being declared final.
All the rest are unnecessary. However, it is just a matter of opinion and
not something worth fighting about (but definitely worth discussing just
because it is interesting).
Yes, interesting chat! :)
Gary
>
> While I have no great objection to this I find it to be of minimal value.
> In general, methods and blocks should be fairly short so the "clarity"
> declaring these variable final provides isn't of much value to me.
>
Great point, "clarity" yes, but clarity *of intent* is my goal, which is
different than clarity of coding in the fewest amount of characters a la C.
I'm no great believer of "self-documenting" code, but using final helps say
"this name is not a variable, it is a constant".
Interesting argument. But I would argue that none of the local variables
marked as final (even the variables I noted above) are actually
"constants". Rather, they are variables whose values do not happen to
change within the block of code they occur in. From that point of view,
I'm not really sure I care. If I need to come along tomorrow and cause the
value to change for whatever reason I'm going to do it. Since that would
happen within the scope of a few lines of code having the final keyword
doesn't help me much.
Ralph
Re: [v2] final keyword
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jan 10, 2013, at 4:23 PM, Gary Gregory wrote:
>
> It all depends on what "..." contains doesn't it? If it's a simple one-liner-single-method-call-with-no-args, the "final" may seem overkill, but it is more complex it is not IMO. This is all about communicating intent. I prefer to use final consistently than making a judgement call on whether this or that declaration benefits. Either the value is constant or it is not.
Yes, it is true that what "..." contains matters. I would argue that in the specific case of LogManager that within the static block the declarations of managerProps, factoryClass and cl are worthy of being declared final. All the rest are unnecessary. However, it is just a matter of opinion and not something worth fighting about (but definitely worth discussing just because it is interesting).
>
>
> While I have no great objection to this I find it to be of minimal value. In general, methods and blocks should be fairly short so the "clarity" declaring these variable final provides isn't of much value to me.
>
> Great point, "clarity" yes, but clarity *of intent* is my goal, which is different than clarity of coding in the fewest amount of characters a la C. I'm no great believer of "self-documenting" code, but using final helps say "this name is not a variable, it is a constant".
Interesting argument. But I would argue that none of the local variables marked as final (even the variables I noted above) are actually "constants". Rather, they are variables whose values do not happen to change within the block of code they occur in. From that point of view, I'm not really sure I care. If I need to come along tomorrow and cause the value to change for whatever reason I'm going to do it. Since that would happen within the scope of a few lines of code having the final keyword doesn't help me much.
Ralph
Re: [v2] final keyword
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, Jan 10, 2013 at 6:53 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I agree, with the exception of local variables. If you look at the last
> commits he made they were primarily to mark variables defined within a
> method as final. From a compiler/performance point of view these don't
> provide any real value. For example, one of the changes Gary made was
> similar to
>
> from
>
> Iterator<Provider> providers = ProviderUtil.getProviders();
> while (providers.hasNext()) {
> Provider provider = provider.next();
> ....
> }
>
> to
>
> final Iterator<Provider> providers = ProviderUtil.getProviders();
> while (providers.hasNext()) {
> final Provider provider = provider.next();
> ...
> }
>
It all depends on what "..." contains doesn't it? If it's a simple
one-liner-single-method-call-with-no-args, the "final" may seem overkill,
but it is more complex it is not IMO. This is all about communicating
intent. I prefer to use final consistently than making a judgement call on
whether this or that declaration benefits. Either the value is constant or
it is not.
>
> While I have no great objection to this I find it to be of minimal value.
> In general, methods and blocks should be fairly short so the "clarity"
> declaring these variable final provides isn't of much value to me.
>
Great point, "clarity" yes, but clarity *of intent* is my goal, which is
different than clarity of coding in the fewest amount of characters a la C.
I'm no great believer of "self-documenting" code, but using final helps say
"this name is not a variable, it is a constant".
Gary
> Ralph
>
> On Jan 10, 2013, at 3:12 PM, Jacob Kjome wrote:
>
> >
> > +1
> >
> > I couldn't agree with Gary more. The "final" keyword is an essential
> element to bug free programs for all the reasons he provides.
> >
> > Jake
> >
> > On Thu, 10 Jan 2013 16:59:08 -0500
> > Gary Gregory <ga...@gmail.com> wrote:
> >> Hi,
> >> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers <
> ralph.goers@dslextreme.com>wrote:
> >>> I guess I should have replied.
> >>>
> >>> My attitude is "I don't care but don't expect me to always do it".
> >>>
> >> Sure, to each his own :)
> >>> Mainly, this is because I have no idea what, if any, benefit there
> is to
> >>> declaring a variable that is local to a method as final. They don't
> affect
> >>> thread safety and, as far as I am aware, don't improve the performance
> of
> >>> the code. If you can find something that shows significant benefit
> then
> >>> maybe I'll get in the habit of doing it too.
> >>>
> >> What I like about final on locals is that it lets me define and guard
> >> "local constants" that I cannot modify because the compiler will
> complain.
> >> This lets me put in code my intention that a local var should not be
> >> modified.
> >> It helps avoid coding mistakes.
> >> Putting final on params formalizes the convention that parms should not
> be
> >> overwritten, if you like that convention that is. IMO, it makes
> debugging
> >> easier and coding easier, you know that when you access a final param
> >> value, it has not been changed.
> >>> As far as class variables, those I have a much stronger opinion about.
> >>> They should be declared final whenever possible.
> >>>
> >> Same for instance variable when possible if immutable objects are
> desired
> >> for thread-safety.
> >> Cheers,
> >> Gary
> >>>
> >>> Ralph
> >>>
> >>>
> >>>
> >>>
> >>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
> >>>
> >>> Since there is no negative feedback, I'll add final keywords.
> >>>
> >>> Gary
> >>>
> >>>
> >>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >>>
> >>>> Hi All:
> >>>>
> >>>> The final keyword in trunk: sometimes it is used, sometimes not. I
> >>>> propose we use it all over consistently.
> >>>>
> >>>> Gary
> >>>>
> >>>> --
> >>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
> >>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >>>> Blog: http://garygregory.wordpress.com
> >>>> Home: http://garygregory.com/
> >>>> Tweet! http://twitter.com/GaryGregory
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
> >>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >>> Blog: http://garygregory.wordpress.com
> >>> Home: http://garygregory.com/
> >>> Tweet! http://twitter.com/GaryGregory
> >>>
> >>>
> >>>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [v2] final keyword
Posted by Jacob Kjome <ho...@visi.com>.
Really? Final variables don't provide any compiler optimization in a loop?
Anyway, I'd have changed it to...
for (final Provider provider : ProviderUtil.getProviders()) {
//do some stuff...
}
Not all method blocks are only 3 lines long, and it's not always just one or
two people working on the code. Final variables provide intention. Some
local vars are meant to be overwritten. When they are not, they should be
explicitly declared as such, which makes it a compiler error when someone
accidentally tries to modify it. Whether or not you think this provides much
benefit, it does eliminate one class of potential bugs, which is a good thing.
Besides, they are essential if you want to reference a local variable in a
closure, or locally implemented callback method, though I suspect you'd have
no argument with that.
Jake
On Thu, 10 Jan 2013 17:55:31 -0600
Paul Benedict <pb...@apache.org> wrote:
> I don't think we need final or any local variables unless the language
> mandates it. I think it just adds noise.
>
> Paul
>
> On Thu, Jan 10, 2013 at 5:53 PM, Ralph Goers <ra...@dslextreme.com>
>wrote:
>> I agree, with the exception of local variables. If you look at the last
>>commits he made they were primarily to mark variables defined within a method
>>as final. From a compiler/performance point of view these don't provide any
>>real value. For example, one of the changes Gary made was similar to
>>
>> from
>>
>> Iterator<Provider> providers = ProviderUtil.getProviders();
>> while (providers.hasNext()) {
>> Provider provider = provider.next();
>> ....
>> }
>>
>> to
>>
>> final Iterator<Provider> providers = ProviderUtil.getProviders();
>> while (providers.hasNext()) {
>> final Provider provider = provider.next();
>> ...
>> }
>>
>> While I have no great objection to this I find it to be of minimal value.
>> In general, methods and blocks should be fairly short so the "clarity"
>>declaring these variable final provides isn't of much value to me.
>>
>> Ralph
>>
>> On Jan 10, 2013, at 3:12 PM, Jacob Kjome wrote:
>>
>>>
>>> +1
>>>
>>> I couldn't agree with Gary more. The "final" keyword is an essential
>>>element to bug free programs for all the reasons he provides.
>>>
>>> Jake
>>>
>>> On Thu, 10 Jan 2013 16:59:08 -0500
>>> Gary Gregory <ga...@gmail.com> wrote:
>>>> Hi,
>>>> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers
>>>><ra...@dslextreme.com>wrote:
>>>>> I guess I should have replied.
>>>>>
>>>>> My attitude is "I don't care but don't expect me to always do it".
>>>>>
>>>> Sure, to each his own :)
>>>>> Mainly, this is because I have no idea what, if any, benefit there is to
>>>>> declaring a variable that is local to a method as final. They don't affect
>>>>> thread safety and, as far as I am aware, don't improve the performance of
>>>>> the code. If you can find something that shows significant benefit then
>>>>> maybe I'll get in the habit of doing it too.
>>>>>
>>>> What I like about final on locals is that it lets me define and guard
>>>> "local constants" that I cannot modify because the compiler will complain.
>>>> This lets me put in code my intention that a local var should not be
>>>> modified.
>>>> It helps avoid coding mistakes.
>>>> Putting final on params formalizes the convention that parms should not be
>>>> overwritten, if you like that convention that is. IMO, it makes debugging
>>>> easier and coding easier, you know that when you access a final param
>>>> value, it has not been changed.
>>>>> As far as class variables, those I have a much stronger opinion about.
>>>>> They should be declared final whenever possible.
>>>>>
>>>> Same for instance variable when possible if immutable objects are desired
>>>> for thread-safety.
>>>> Cheers,
>>>> Gary
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>>>>>
>>>>> Since there is no negative feedback, I'll add final keywords.
>>>>>
>>>>> Gary
>>>>>
>>>>>
>>>>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com>wrote:
>>>>>
>>>>>> Hi All:
>>>>>>
>>>>>> The final keyword in trunk: sometimes it is used, sometimes not. I
>>>>>> propose we use it all over consistently.
>>>>>>
>>>>>> Gary
>>>>>>
>>>>>> --
>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>>>> Blog: http://garygregory.wordpress.com
>>>>>> Home: http://garygregory.com/
>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Paul Benedict <pb...@apache.org>.
I don't think we need final or any local variables unless the language
mandates it. I think it just adds noise.
Paul
On Thu, Jan 10, 2013 at 5:53 PM, Ralph Goers <ra...@dslextreme.com> wrote:
> I agree, with the exception of local variables. If you look at the last commits he made they were primarily to mark variables defined within a method as final. From a compiler/performance point of view these don't provide any real value. For example, one of the changes Gary made was similar to
>
> from
>
> Iterator<Provider> providers = ProviderUtil.getProviders();
> while (providers.hasNext()) {
> Provider provider = provider.next();
> ....
> }
>
> to
>
> final Iterator<Provider> providers = ProviderUtil.getProviders();
> while (providers.hasNext()) {
> final Provider provider = provider.next();
> ...
> }
>
> While I have no great objection to this I find it to be of minimal value. In general, methods and blocks should be fairly short so the "clarity" declaring these variable final provides isn't of much value to me.
>
> Ralph
>
> On Jan 10, 2013, at 3:12 PM, Jacob Kjome wrote:
>
>>
>> +1
>>
>> I couldn't agree with Gary more. The "final" keyword is an essential element to bug free programs for all the reasons he provides.
>>
>> Jake
>>
>> On Thu, 10 Jan 2013 16:59:08 -0500
>> Gary Gregory <ga...@gmail.com> wrote:
>>> Hi,
>>> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>>> I guess I should have replied.
>>>>
>>>> My attitude is "I don't care but don't expect me to always do it".
>>>>
>>> Sure, to each his own :)
>>>> Mainly, this is because I have no idea what, if any, benefit there is to
>>>> declaring a variable that is local to a method as final. They don't affect
>>>> thread safety and, as far as I am aware, don't improve the performance of
>>>> the code. If you can find something that shows significant benefit then
>>>> maybe I'll get in the habit of doing it too.
>>>>
>>> What I like about final on locals is that it lets me define and guard
>>> "local constants" that I cannot modify because the compiler will complain.
>>> This lets me put in code my intention that a local var should not be
>>> modified.
>>> It helps avoid coding mistakes.
>>> Putting final on params formalizes the convention that parms should not be
>>> overwritten, if you like that convention that is. IMO, it makes debugging
>>> easier and coding easier, you know that when you access a final param
>>> value, it has not been changed.
>>>> As far as class variables, those I have a much stronger opinion about.
>>>> They should be declared final whenever possible.
>>>>
>>> Same for instance variable when possible if immutable objects are desired
>>> for thread-safety.
>>> Cheers,
>>> Gary
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>>>>
>>>> Since there is no negative feedback, I'll add final keywords.
>>>>
>>>> Gary
>>>>
>>>>
>>>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com>wrote:
>>>>
>>>>> Hi All:
>>>>>
>>>>> The final keyword in trunk: sometimes it is used, sometimes not. I
>>>>> propose we use it all over consistently.
>>>>>
>>>>> Gary
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>>
>>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Ralph Goers <ra...@dslextreme.com>.
I agree, with the exception of local variables. If you look at the last commits he made they were primarily to mark variables defined within a method as final. From a compiler/performance point of view these don't provide any real value. For example, one of the changes Gary made was similar to
from
Iterator<Provider> providers = ProviderUtil.getProviders();
while (providers.hasNext()) {
Provider provider = provider.next();
....
}
to
final Iterator<Provider> providers = ProviderUtil.getProviders();
while (providers.hasNext()) {
final Provider provider = provider.next();
...
}
While I have no great objection to this I find it to be of minimal value. In general, methods and blocks should be fairly short so the "clarity" declaring these variable final provides isn't of much value to me.
Ralph
On Jan 10, 2013, at 3:12 PM, Jacob Kjome wrote:
>
> +1
>
> I couldn't agree with Gary more. The "final" keyword is an essential element to bug free programs for all the reasons he provides.
>
> Jake
>
> On Thu, 10 Jan 2013 16:59:08 -0500
> Gary Gregory <ga...@gmail.com> wrote:
>> Hi,
>> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>> I guess I should have replied.
>>>
>>> My attitude is "I don't care but don't expect me to always do it".
>>>
>> Sure, to each his own :)
>>> Mainly, this is because I have no idea what, if any, benefit there is to
>>> declaring a variable that is local to a method as final. They don't affect
>>> thread safety and, as far as I am aware, don't improve the performance of
>>> the code. If you can find something that shows significant benefit then
>>> maybe I'll get in the habit of doing it too.
>>>
>> What I like about final on locals is that it lets me define and guard
>> "local constants" that I cannot modify because the compiler will complain.
>> This lets me put in code my intention that a local var should not be
>> modified.
>> It helps avoid coding mistakes.
>> Putting final on params formalizes the convention that parms should not be
>> overwritten, if you like that convention that is. IMO, it makes debugging
>> easier and coding easier, you know that when you access a final param
>> value, it has not been changed.
>>> As far as class variables, those I have a much stronger opinion about.
>>> They should be declared final whenever possible.
>>>
>> Same for instance variable when possible if immutable objects are desired
>> for thread-safety.
>> Cheers,
>> Gary
>>>
>>> Ralph
>>>
>>>
>>>
>>>
>>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>>>
>>> Since there is no negative feedback, I'll add final keywords.
>>>
>>> Gary
>>>
>>>
>>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com>wrote:
>>>
>>>> Hi All:
>>>>
>>>> The final keyword in trunk: sometimes it is used, sometimes not. I
>>>> propose we use it all over consistently.
>>>>
>>>> Gary
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Jacob Kjome <ho...@visi.com>.
+1
I couldn't agree with Gary more. The "final" keyword is an essential element
to bug free programs for all the reasons he provides.
Jake
On Thu, 10 Jan 2013 16:59:08 -0500
Gary Gregory <ga...@gmail.com> wrote:
> Hi,
>
> On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers
><ra...@dslextreme.com>wrote:
>
>> I guess I should have replied.
>>
>> My attitude is "I don't care but don't expect me to always do it".
>>
>
> Sure, to each his own :)
>
>
>> Mainly, this is because I have no idea what, if any, benefit there is to
>> declaring a variable that is local to a method as final. They don't affect
>> thread safety and, as far as I am aware, don't improve the performance of
>> the code. If you can find something that shows significant benefit then
>> maybe I'll get in the habit of doing it too.
>>
>
> What I like about final on locals is that it lets me define and guard
> "local constants" that I cannot modify because the compiler will complain.
> This lets me put in code my intention that a local var should not be
> modified.
> It helps avoid coding mistakes.
>
> Putting final on params formalizes the convention that parms should not be
> overwritten, if you like that convention that is. IMO, it makes debugging
> easier and coding easier, you know that when you access a final param
> value, it has not been changed.
>
>
>> As far as class variables, those I have a much stronger opinion about.
>> They should be declared final whenever possible.
>>
>
> Same for instance variable when possible if immutable objects are desired
> for thread-safety.
>
> Cheers,
> Gary
>
>>
>> Ralph
>>
>>
>>
>>
>> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>>
>> Since there is no negative feedback, I'll add final keywords.
>>
>> Gary
>>
>>
>> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com>wrote:
>>
>>> Hi All:
>>>
>>> The final keyword in trunk: sometimes it is used, sometimes not. I
>>> propose we use it all over consistently.
>>>
>>> Gary
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [v2] final keyword
Posted by Gary Gregory <ga...@gmail.com>.
Hi,
On Thu, Jan 10, 2013 at 4:39 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> I guess I should have replied.
>
> My attitude is "I don't care but don't expect me to always do it".
>
Sure, to each his own :)
> Mainly, this is because I have no idea what, if any, benefit there is to
> declaring a variable that is local to a method as final. They don't affect
> thread safety and, as far as I am aware, don't improve the performance of
> the code. If you can find something that shows significant benefit then
> maybe I'll get in the habit of doing it too.
>
What I like about final on locals is that it lets me define and guard
"local constants" that I cannot modify because the compiler will complain.
This lets me put in code my intention that a local var should not be
modified.
It helps avoid coding mistakes.
Putting final on params formalizes the convention that parms should not be
overwritten, if you like that convention that is. IMO, it makes debugging
easier and coding easier, you know that when you access a final param
value, it has not been changed.
> As far as class variables, those I have a much stronger opinion about.
> They should be declared final whenever possible.
>
Same for instance variable when possible if immutable objects are desired
for thread-safety.
Cheers,
Gary
>
> Ralph
>
>
>
>
> On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
>
> Since there is no negative feedback, I'll add final keywords.
>
> Gary
>
>
> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com>wrote:
>
>> Hi All:
>>
>> The final keyword in trunk: sometimes it is used, sometimes not. I
>> propose we use it all over consistently.
>>
>> Gary
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977/>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [v2] final keyword
Posted by Ralph Goers <ra...@dslextreme.com>.
I guess I should have replied.
My attitude is "I don't care but don't expect me to always do it". Mainly, this is because I have no idea what, if any, benefit there is to declaring a variable that is local to a method as final. They don't affect thread safety and, as far as I am aware, don't improve the performance of the code. If you can find something that shows significant benefit then maybe I'll get in the habit of doing it too.
As far as class variables, those I have a much stronger opinion about. They should be declared final whenever possible.
Ralph
On Jan 10, 2013, at 12:15 PM, Gary Gregory wrote:
> Since there is no negative feedback, I'll add final keywords.
>
> Gary
>
>
> On Tue, Oct 9, 2012 at 9:08 AM, Gary Gregory <ga...@gmail.com> wrote:
> Hi All:
>
> The final keyword in trunk: sometimes it is used, sometimes not. I propose we use it all over consistently.
>
> Gary
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory