Any ideas how to avoid this code checker error?
in [Java Programming]
|
From: Arne Vajhøj on 29 Jan 2010 22:09 On 29-01-2010 19:46, Wojtek wrote: > So it is limited to primitives or String. Ok, then what would you call > this? Like String it is barred from being modified after initialisation. > > -------------------------------- > public class Foo > { > public static final MyObject OBJECT_SOME = new MyObject("some parm"); > public static final MyObject OBJECT_TWO = new MyObject("two parm"); The reference can not be modified like a static final String. But the object can be modified unlike a static final String. Arne
From: John B. Matthews on 29 Jan 2010 22:22 In article <hk03fa$4i6$2(a)news.albasani.net>, Lew <noone(a)lewscanon.com> wrote: > Peter Duniho wrote: > > Lew wrote: > >> If John jumped off a bridge, would you do that, too? > > > > I dunno. I wouldn't do that for just anyone. But John's a pretty smart > > guy; if I see him doing something, I might wonder if there might > > actually be something to it after all. :p > > That is a very measured and respectable answer. If you had added, > "Provided my ankles were secured by a bungee cord," I'd see why you > were willing to follow suit. Aiiieee! You guys go ahead. If needed, I'll administer first-aid until the ambulance arrives. -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Arne Vajhøj on 29 Jan 2010 22:47 On 29-01-2010 16:13, Wojtek wrote: > I am not confused at all. If it is static and final, then it is a class > constant. The fact that it has attributes which can be modified (if > exposed) is a moot point. The _reference_ cannot be changed, and so it > is a constant. Give that the .equals to == ratio for objects probably is 100:1, then I question the benefits from your definition. > Where I use classes as constants, I also make sure that there are no > setters, which preserves the original state of the object. Then it is another matter. Arne
From: Wojtek on 2 Feb 2010 10:29 Lew wrote : > I'd have even more faith if you provided Javadocs for the public members that > asserted the immutability. In an off-the-cuff example to a news group? -- Wojtek :-)
From: Lew on 2 Feb 2010 11:32
Lew wrote : >> I'd have even more faith if you provided Javadocs for the public >> members that asserted the immutability. Wojtek wrote: > In an off-the-cuff example to a news group? Sigh. In general. I'm speaking of general principles, here. The context of my remarks was coding conventions, and my point was about where they do not suffice to indicate constancy. Even in your off-the-cuff example, which I took to be representative of general principle, pardon my error, the spelling of 'OBJECT_SOME' doesn't suffice to aver immutability. One needs source code access or a promise in the Javadocs to have faith in that. I will reiterate, hopefully less confusingly. Simply spelling the name of a non-constant variable in all upper-case letters does not, *in general*, assure the client or maintainer of immutability. One needs additional documentation such as Javadocs or an annotation to have more confidence that the author at least tried for immutability. Generally speaking, that is, and as would appear in the real world. I should think that since you proffered your example as illustrative of general principle that you wouldn't resort to reversing that stance in order to get a gripe in. Silly me. -- Lew |