Const correctness (was Re: Oppinion on 'least priviledge', 'const correctness', etc.)
in [Java Programming]
|
Prev: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)
Next: Mutable Objects and Thread Boundaries
From: Öö Tiib on 20 Jul 2010 14:38 On 20 juuli, 20:54, Peter Duniho <NpOeStPe...(a)NnOwSlPiAnMk.com> wrote: > Lew wrote: > > I'm a big fan of language constructs that constrain the code in certain > ways, from data/implementation hiding/encapsulation to things like > "const", "final", "readonly" (C#), etc. that help convey and, > especially, enforce intent. But these kinds of things really need to be > done in a way that doesn't allow the programmer to just wish the > restrictions away any time they like. Otherwise, it's too tempting to > do just that when the alternative is to spend hours or days updating the > code to use the restriction properly. C++ is yes, relatively anarchistic language so teams usually agree upon policies that they follow and do not expect software (compiler) to tell to human how to program it. There are always ways to circumvent the language protection mechanics. If i remember correctly then calling private member functions in C# is even easier than in C+ +. If something evil gets too annoyingly tempting then build gallons ... few public executions later it is less tempting.
From: Daniel Pitts on 20 Jul 2010 16:39 On 7/20/2010 10:33 AM, Lew wrote: > On Jul 20, 10:18 am, Jorgen Grahn<grahn+n...(a)snipabacken.se> wrote: >> ["Followup-To:" header set to comp.lang.c++. Neither the Java nor the >> comp.programming people want to read about const correctness, I'm sure.] >> > > Don't be so sure. Java has 'final', which isn't exactly the same as > 'const' but is similar and applies similarly to the "principle of > least privilege" and the safety thereof. > > Both 'const' and 'final' express the intention to prevent change to a > variable's value. Almost. const expresses that a specific object should be unchanged, but final (unfortunately) only refers to primitive/reference immutability. It is definitely a feature I miss in Java. Especially since immutable objects are guaranteed to be thread-safe. -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
From: Esmond Pitt on 20 Jul 2010 22:33 On 21/07/2010 3:33 AM, Lew wrote: > Don't be so sure. Java has 'final', which isn't exactly the same as > 'const' but is similar It's not really all that similar. As Jorgen says, C++ 'const' becomes part of the type system, and it's so type-safe that if you add/remove const to/from a method argument declaration the program will stop linking. Java doesn't have that property at all. Callers don't benefit from 'final' parameters in any way, only the author of the method ... which is why I've always found 'final' method parameters pretty pointless unless there's an inner class.
From: Lew on 20 Jul 2010 23:50 Lew wrote: >> Don't be so sure. Java has 'final', which isn't exactly the same as >> 'const' but is similar Esmond Pitt wrote: > It's not really all that similar. As Jorgen says, C++ 'const' becomes > part of the type system, and it's so type-safe that if you add/remove > const to/from a method argument declaration the program will stop > linking. Java doesn't have that property at all. Callers don't benefit > from 'final' parameters in any way, only the author of the method ... > which is why I've always found 'final' method parameters pretty > pointless unless there's an inner class. Java method parameters are pass-by-value, so of course 'final' will work differently on them. Java doesn't need to make 'final' part of the method signature because changes to the parameters are not visible to the caller anyway. The only thing left for 'final' to do is what it does, to make it impossible for the called routine to change what the argument points to. So of course "callers don't benefit" from them - but the similarity is there insofar as it prevents change within the method. As for changing the values in structures to which the argument points, that isn't prevented in C++ by making a pointer 'const', only by making the thing to which it points 'const', something that Java does and for which it uses - guess what? - 'final'. It does a similar thing, just in a different way. No one is saying that 'final' and 'const' are the same. If you think that's my point, you haven't been reading my posts. The languages themselves differ, so there's no way they can be the same, like in the case of method arguments. But they are similar, insofar as both prevent change to the variable to which they're attached. I do agree that 'final' for Java method arguments is not the most useful use case. It's far more handy for class members and local variables. -- Lew
From: Peter Duniho on 21 Jul 2010 00:06
Lew wrote: > Lew wrote: >>> Don't be so sure. Java has 'final', which isn't exactly the same as >>> 'const' but is similar > > Esmond Pitt wrote: >> It's not really all that similar. As Jorgen says, C++ 'const' becomes >> part of the type system, and it's so type-safe that if you add/remove >> const to/from a method argument declaration the program will stop >> linking. Java doesn't have that property at all. Callers don't benefit >> from 'final' parameters in any way, only the author of the method ... >> which is why I've always found 'final' method parameters pretty >> pointless unless there's an inner class. > > Java method parameters are pass-by-value, so of course 'final' will work > differently on them. In C++, a reference passed by value can still be to a "const" type, preventing the method declaring the parameter as "const" from modifying the object (i.e. it can only call "const" methods in the object, and can only pass the reference to methods that declare the parameter's type as "const"). In Java, all references are passed by value (of course), but "final" does _not_ provide this same feature. > Java doesn't need to make 'final' part of the > method signature because changes to the parameters are not visible to > the caller anyway. The only thing left for 'final' to do is what it > does, to make it impossible for the called routine to change what the > argument points to. So of course "callers don't benefit" from them - > but the similarity is there insofar as it prevents change within the > method. Java's "final" _could_ have applied to the type, as it does in C++. But it doesn't. This is what everyone is trying to point out to you. The fact that Java doesn't have pass-by-reference in no way makes "const" and "final" equivalent. Even ignoring pass-by-reference in C++, "const" still is a stronger guarantee than "final" in Java. > As for changing the values in structures to which the argument points, > that isn't prevented in C++ by making a pointer 'const', only by making > the thing to which it points 'const', something that Java does and for > which it uses - guess what? - 'final'. It does a similar thing, just in > a different way. No, it doesn't. Java doesn't have any way to prevent values in structures to which the argument points from being modified. Not in the parameter declaration, that is. You can, of course, make the fields in a class "final", preventing them from being modified. But that would prevent them from being modified _ever_. Applying "const" to a type in a parameter list in C++ only prevents modification _in that method_. The object can still be modified later elsewhere. > No one is saying that 'final' and 'const' are the same. If you think > that's my point, you haven't been reading my posts. The languages > themselves differ, so there's no way they can be the same, like in the > case of method arguments. But they are similar, insofar as both prevent > change to the variable to which they're attached. Many of your posts have seemed to be claiming that "const" in C++ is similar enough to "final" so as there to not be any point in discussing what's different. C++'s "const" is actually quite a bit different from "final" in Java, sharing only one small aspect of its behavior with Java's "final". > I do agree that 'final' for Java method arguments is not the most useful > use case. It's far more handy for class members and local variables. Well, inasmuch as method parameters are really just locals that have been initialized by the method call itself, it has the same utility for method parameters as for local variables. The primary practical use being to allow the variable to be used in an anonymous class. Pete |