Oppinion on 'least priviledge', 'const correctness', etc.
in [General Programming]
|
Prev: Simple Hack TO Get $1500 To Your PayPal Account.
Next: Const correctness (was Re: Oppinion on 'least priviledge', 'constcorrectness', etc.)
From: Lew on 20 Jul 2010 21:00 Lew wrote: >>>> Wrong again, sort of. Java has 'final' which is sort of similar to >>>> 'const'. Öö Tiib wrote: >>> I have not seen much usage of it nor heard much talk about 'final- >>> correctness' in friendly java [sic] teams. C devs talk about const a lot That's because that's not what we call it. Alan gives you the correct term. >>> more. Perhaps that 'final' sort of misses some useful perks of >>> 'const'. Or perhaps Java's 'final' doesn't need those "perks" because of the other differences between the languages. Jonathan Lee wrote: >> I've never heard of an equivalent of "const correctness" in Java, Therefore it doesn't exist? Anyway, the claim isn't that there's an exact equivalent to "const correctness" but that Java's 'final' has similarities to C++'s 'const', and relative to the Java language fills the same ecological niche. >> but I also don't use it very much. Though, a quick Google search >> seems to support the idea that "final" is really nothing like >> const-correctness: Again, that's not the claim. The claim is that 'final' is similar for Java to what 'const' is in C++, in certain ways. Alan Gutierrez wrote: > The equivalent in Java to "const-Correctness", culturally, is "Favor > Immutability". The same sort of conversation taking place here is one > that follows a request to explain the benefits of "Favor Immutability". > > I'm new here, and I humbly submit the above observation. Everyone here seems to think that Java 'final' is just nothing a-'tall like C[++] 'const'. They are, of course, mistaken. Both keywords signal to the compiler that the item so marked cannot be altered. Since Java supports only pointers and primitives and not value-object variables, the semantics of its 'final' are bound to differ from those of C++'s 'const'. C++ and Java are different languages. But in terms of enforcing "least privilege" (this conversation's avowed topic) and immutability, the two constructs serve cognate purposes. -- Lew
From: Daniel on 20 Jul 2010 22:46 On Jul 20, 2:14 pm, Jonathan Lee <jonathan.lee....(a)gmail.com> wrote: > On Jul 20, 2:04 pm, Öö Tiib <oot...(a)hot.ee> wrote: > > I've never heard of an equivalent of "const correctness" in Java, > but I also don't use it very much. Neither Java or C++ has any way of marking a function as "pure". In Java, the convention is more to use immutable interfaces, so the issue doesn't arise as much. In C++, const restricts you to calling a subset of member functions on the object, but there are no guarantees that that subset doesn't also change state, there are restrictions, but only to the first layer of the data. -- Daniel
From: Lew on 20 Jul 2010 23:55 Daniel wrote: > Neither Java or C++ has any way of marking a function as "pure". In > Java, the convention is more to use immutable interfaces, so the issue Immutable class instances. Interfaces in Java can't enforce immutability. > doesn't arise as much. In C++, const restricts you to calling a > subset of member functions on the object, but there are no guarantees > that that subset doesn't also change state, there are restrictions, > but only to the first layer of the data. -- Lew
From: Öö Tiib on 21 Jul 2010 02:04 On 21 juuli, 04:00, Lew <no...(a)lewscanon.com> wrote: > Öö Tiib wrote: > >>> I have not seen much usage of it nor heard much talk about 'final- > >>> correctness' in friendly java [sic] teams. C devs talk about const a lot > > That's because that's not what we call it. Alan gives you the correct term. Seems that "Favor Immutability" is not that popular idiom. Google for "Const Correctness" 39,000 results, "Favor Immutability" 1,080. It is more about how to create immutable classes, while in C++ you do not need to (but may) make special classes for constant instances. > >>> more. Perhaps that 'final' sort of misses some useful perks of > >>> 'const'. > > Or perhaps Java's 'final' doesn't need those "perks" because of the other > differences between the languages. Huh? But these are tools, language features. Not mandatory to use always but most like them since these really help. Perhaps that 'final' is simply considered enough by authors of java. There are fine languages like Python with even less features supporting immutability. > >> but I also don't use it very much. Though, a quick Google search > >> seems to support the idea that "final" is really nothing like > >> const-correctness: > > Again, that's not the claim. The claim is that 'final' is similar for Java to > what 'const' is in C++, in certain ways. Ok. Making primitive immutable with 'final' is yes in certain ways same. It is mostly perhaps used for naming single constant values, not write protection? You can also make a pointer immutable with 'final'. That is sometimes done in C++ too but usually one uses a reference for it ('const' is not needed at all). There similarities end. 'final' about member function means that it can not be further overridden and 'final' about class means that it can not be derived from. These are entirely different purposes than 'const' has. It feels like 'final' is for some sort of global and meta- immutability when 'const' is more for selectively write-protecting (possibly mutable) data. > Everyone here seems to think that Java 'final' is just nothing a-'tall like > C[++] 'const'. They are, of course, mistaken. 'const' yes, feels more oriented for not giving (and taking) unneeded privileges locally. Major feature of 'const' is to declare that code will not modify the object pointed to by a pointer through that pointer. Other feature is to declare that function does not modify its parameter and third is to show that member function does not modify the object. How you do any of these with 'final'? > Both keywords signal to the compiler that the item so marked cannot be altered. > > Since Java supports only pointers and primitives and not value-object > variables, the semantics of its 'final' are bound to differ from those of > C++'s 'const'. C++ and Java are different languages. But in terms of > enforcing "least privilege" (this conversation's avowed topic) and > immutability, the two constructs serve cognate purposes. I am not saying that different feature set makes one language better than other, just that 'final's purpose feels different and such comparison feels stretched out, nothing to do. You can have immutable view of mutable data by writing special interface in java, but the cost is higher than with 'const' and what it all has to do with 'final'?
From: Lew on 21 Jul 2010 09:29
Öö Tiib wrote: > Seems that "Favor Immutability" is not that popular idiom. Google for It's one of the most fundamental idioms in Java. > "Const Correctness" 39,000 results, "Favor Immutability" 1,080. It is That's a measure of how often a particular phrase turns up, not how often the topic comes up. Your "research' is a complete red herring. > more about how to create immutable classes, while in C++ you do not > need to (but may) make special classes for constant instances. Yeesh. "How to create immutable classes" *is* a discussion of "favor immutability". How come you didn't include those stats in your count? Hm? The keywords differ in how they're applied. Maybe Java doesn't use a fancy term; when discussing immutability and final we just say, "making things final" or "making things immutable" or other phrases with the word "final" and "immutable", and everyone understands that we talk about that because of the advice to "favor immutability" without having to quote that particular chapter title. No one lasts long in Java without hearing about Joshua Bloch's /Effective Java/, whence came the phrase "favor immutability", and no one progresses far as a Java programmer without studying that book. So strengthen your google-fu and try again, and don't quote misleading and irrelevant statistics. Lew wrote: >> Or perhaps Java's 'final' doesn't need those "perks" because of the other >> differences between the languages. Öö Tiib wrote: > Huh? But these are tools, language features. Not mandatory to use > always but most like them since these really help. Perhaps that > 'final' is simply considered enough by authors of java [sic]. There are fine > languages like Python with even less features supporting > immutability. As we've established elsethread, 'final' and 'const' are somewhat similar in certain respects, but not the same really. They fill a niche of immutability in different languages with different ecologies, and do so at somewhat different levels. I stand corrected (thanks, Pete) on any implication that the keywords are highly similar. I never intended to imply that. All I'm saying is that they have a similarity in purpose, to render elements immutable. Lew wrote: >> Again, that's not the claim. The claim is that 'final' is similar for Java to >> what 'const' is in C++, in certain ways. Öö Tiib wrote: > Ok. Making primitive immutable with 'final' is yes in certain ways > same. It is mostly perhaps used for naming single constant values, not > write protection? You can also make a pointer immutable with 'final'. > That is sometimes done in C++ too but usually one uses a reference for > it ('const' is not needed at all). Java doesn't have C++ references; what Java calls "reference" is actually a pointer. > There similarities end. 'final' about member function means that it > can not be further overridden and 'final' about class means that it > can not be derived from. These are entirely different purposes than I was only referring to the use of 'final' for variables. Method and class names already cannot be changed to point to something different. > 'const' has. It feels like 'final' is for some sort of global and meta- > immutability when 'const' is more for selectively write-protecting > (possibly mutable) data. 'final' serves that purpose in Java. Lew wrote: >> Everyone here seems to think that Java 'final' is just nothing a-'tall like >> C[++] 'const'. They are, of course, mistaken. Öö Tiib wrote: > 'const' yes, feels more oriented for not giving (and taking) unneeded > privileges locally. Major feature of 'const' is to declare that code > will not modify the object pointed to by a pointer through that > pointer. Other feature is to declare that function does not modify its > parameter and third is to show that member function does not modify > the object. How you do any of these with 'final'? Java cannot access an object by a pointer to a pointer, since those don't even exist, so that purpose isn't needed. 'final' applied to a function parameter has a cognate purpose - the function cannot change the contents of the parameter. To prevent anything (not just a member function) from modifying the object, Java uses 'final', but on the attributes of the object, not the method. Lew wrote: >> Both keywords signal to the compiler that the item so marked cannot be altered. >> >> Since Java supports only pointers and primitives and not value-object >> variables, the semantics of its 'final' are bound to differ from those of >> C++'s 'const'. C++ and Java are different languages. But in terms of >> enforcing "least privilege" (this conversation's avowed topic) and >> immutability, the two constructs serve cognate purposes. Öö Tiib wrote: > I am not saying that different feature set makes one language better Nor am I. > than other, just that 'final's purpose feels different and such The purpose is similar, it's the mechanics that differ. > comparison feels stretched out, nothing to do. You can have immutable > view of mutable data by writing special interface in java [sic], but the Java interfaces cannot enforce immutability. > cost is higher than with 'const' and what it all has to do with > 'final'? Immutability in Java is enforced with 'final', as immutability in C++ is with 'const'. Yes, there are differences, of course. They aren't the same. But given the different ecologies, they have a (sort of) similar purpose. That's what. -- Lew |