Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.help > #449
| From | "Alex Mentis" <foo@invalid.invalid> |
|---|---|
| Newsgroups | comp.lang.java.help |
| Subject | Re: static final int, but constructor with (final int) arguments |
| Date | 2011-03-29 16:03 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <imsvsu$n48$1@dont-email.me> (permalink) |
| References | <87sju7w4o5.fsf@merciadriluca-station.MERCIADRILUCA> <imqh04$osg$1@dont-email.me> <imrrei$k3j$1@news.albasani.net> |
Lew wrote: > Alex Mentis wrote: > > You don't really need to make it final. Since c is declared private, > > the only way that c's value could change is if you write a method > > that assigns a new value to c. As long as you don't do that (and you > > Ah, there's the magic wand. > > "As long as you don't do that ...". > > 'final' engages the compiler's support to make sure that you don't. > > And there are semantics relating to initialization order and > multi-threaded access where 'final' makes a significant difference. > > > shouldn't need to, if c is not supposed to change), the only way c's > > value will ever change is when the object is first created and the > > contructor sets it to whatever value c should have for the object's > > lifetime. > > If this is the scenario, then you really should lock it down with > 'final'. Yes, you're absolutely right. Both you and rossum provided the best solution (use final instead of static final). My response was subpar at best, and it would actually be fair to go as far as calling it "wrong" - especially in this case.
Back to comp.lang.java.help | Previous | Next | Find similar | Unroll thread
Re: static final int, but constructor with (final int) arguments "Alex Mentis" <foo@invalid.invalid> - 2011-03-29 16:03 +0000
csiph-web