Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.help Subject: Re: What qualifies as a constant ? (Was: Reverse sorting an array) Date: Fri, 30 Sep 2011 08:42:23 -0700 (PDT) Organization: http://groups.google.com Lines: 46 Message-ID: <4033162.609.1317397344126.JavaMail.geo-discussion-forums@prib32> References: <8ea2add1-ce9c-423b-bdb8-92c461cf9c6d@5g2000yqo.googlegroups.com> <0tab87dkpjalvsqde3v720ap8h8pa8l2or@4ax.com> <4e85b9e8$0$1080$426a34cc@news.free.fr> <11444264.0.1317393558767.JavaMail.geo-discussion-forums@prfe27> <4e85dd15$0$27982$426a74cc@news.free.fr> Reply-To: comp.lang.java.help@googlegroups.com NNTP-Posting-Host: 67.218.102.85 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1317397684 26231 127.0.0.1 (30 Sep 2011 15:48:04 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 30 Sep 2011 15:48:04 +0000 (UTC) In-Reply-To: <4e85dd15$0$27982$426a74cc@news.free.fr> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=67.218.102.85; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.help:1168 On Friday, September 30, 2011 8:15:55 AM UTC-7, Mayeul wrote: ...=20 > However, the example we're speaking about is not using an instance=20 > constant. It is using a local constant variable. Now, without having=20 > verified it, I expect such constants are not repeated any more than a=20 > class constant would be. It is repeated every time the method is invoked, semantically. Operationally you'd expect a constant load, of course. But my issue here i= s semantic. If it's a constant, as in this example, the value cannot chang= e between invocations or instances, so why scope it so narrowly? One could argue as you do: > I'd expect the point of that is to narrow the variable's scope down to=20 > one single method. The point of /this/ would be... Well, questionable,=20 > okay. I do that when I want to give a meaningful name to a constant=20 > rather an a magical number, but the relevance of it only applies to one= =20 > single method. This usually only happens within classes I feel could be= =20 > refactored more clearly, though. and I agree, particularly that the point is questionable. More significant= ly it isn't consistent with convention and most style recommendations. If = something is a compile-time constant, it /should/ be declared at the class = level, with static final constant variables. Part of this is for maintenan= ce - compile-time constants' class dependency rules differ from other varia= bles (even final immutable ones that aren't compile-time constants). You a= lso get early assignment of 'final' member variables (including non-constan= t ones). These are technical advantages for using true class-level constan= ts, which though perhaps slight still combine with convention to trump a st= yle argument for the questionable practice. In summary: - Upper-case names are limited to class-level constant variables by the cor= e convention. - Compile-time constant variables are treated differently from other variab= les, and such member variables particularly differently. - The convention is to declare such constants as class member variables. - Build and maintenance considerations support that convention for pragmati= c reasons. - Following the convention models the problem semantics more correctly. --=20 Lew