Impromptus

Hmmmm. Not sure I agree with that one. Private, yes, but final?nnThe idea behind a class is that you’re creating a new datatype that, in general, has a state that changes. Therefore, most of the state is, in fact, not final (particularly in the face of primitive types).nnI’d be interested in your reasoning here…I don’t get it.

If you look at the rules of Liskov substitution principle, it is much harder to get all of those rules in agreement with your system if you have instance variables whose value is allowed to change. A classic example asks the question of whether a Rectangle is a refinement of a Square, or whether a Square is a refinement (and therefore should be a subclass of) Rectangle.nnIn general, I think that most people would agree that a Square is a special kind of Rectangle, and not vice-versa. Therefore, we should do

and not the other way around. Unfortunately, the question gets grosser when we look at the third rule of the substitution principle which states “the replacement module should maintain all the invariants of the original”, and look at the problem of mutable Rectangles.nnIf Rectangles are allowed to change their height, via some getHeight()/setHeight() functions and to change their width via some getWidth()/setWidth() function, then we have a problem. Because if a Square is a Rectangle, then we will need to implement setHeight() and setWidth() in Square so that when we change the height, we also change the width. But this means that a Square is not a drop-in replacement for a Rectangle! It breaks the third rule! However, it is only the mutability of these parameters which causes the problems. Therefore, we should force programmers to think and to do extra work whenever they want to add mutation to their classes, as it makes their inheritance hierarchies much harder to get right. Also, declaring things final forces programmers to set all of their class values in the constructor, which is a good habit that is hard to enforce among beginners.nnMost variables ARE final in practice, but most variables that are final-in-practice are not final-in-declaration. Declaring variables to be final makes reasoning easier for both people and the compiler. We should make the hard case require extra work, and make the easy case the default.

While I disagree that private final should be the default, I am 1000% with you that package protects should *not* be. I think private final can be needlessly confusing for new programmers. “Wait, I said this array was final, but I can add things to it?”. But package? I can’t really think of a situation where I would feel it’s best practice to use it ever, let alone default.

Have you tried Clojure?

package protected should not even exist. It is super-dumb.

OK, some nice points. I particularly like:nn- Forces initialization in constructor (which I agree is important, and often wrong)n- Mutability affects getting inheritance correct.n- We should evolve languages to better help programmers correctly express software.nnBut in practice, I have the following issues:nn1. What evidence do you have that most variables ARE final, as you state? I guess I should peruse my own code and see if I agree. Off the top of my head, I think of things like ArrayList, which have no final state at all…the internal array (though hidden) can get reallocated, and the other tracking variables change all the time. Other basic utility classes, like geometry items (circle, rectangle, etc) are all mutable state. I can think of many cases like Integer (which hold immutable state) and things like UI code (e.g. I make a button and my ref to it doesn’t change), but I am not convinced the final case is all that more prevalent.nn2. On getting class hierarchies right: In practice, most “experts” don’t get it right up front. That’s one of the main things agile is about.nnSo while I see your theoretical point about having the language force you to think about the design of mutability, I remain unconvinced in the power of all things final.nnPerhaps I’ll start writing that way and see what evolves.

I’ve played with my own code, and noted:nn1. It is the case that many of my private fields can in fact be final, esp in classes that represent things ala Integer (immutable instances). n2. In other classes (that have mutable state), I find a decent number that could be final, but not an overwhelming majority.n3. Interesting case:nnThe android API has to separate the creation of an activity from the activation. E.g, the constructor is used to make an Activity, but when it comes to the screen a special method (onCreate) is called with important information that is used for that particular use of the activity. I have fields that “want to be” final, but just for that particular use.nnThis implies that there are common APIs where final is insufficient (mostly because the compiler cannot prove single-assignment because of a specialized usage pattern).nnIt would be interesting to talk more about what this language feature should be. I think you’re onto something in terms of a language feature that better expresses these constraints….but final isn’t quite it. nnHow about a modifier on methods that declares them to be (re)initializers, which are the only methods allowed to modify final items?nnInteresting…

Truly! I’ll admit that during the transition from c that package did feel natural. But that was only because I was developing as a c developer in java essentially, which caused much unneeded pain.