Mutable Strings + Hungarian Notation + Security = ???
How to make Java Strings mutable, without breaking the Java security model, and in doing so how to look at the Hungarian / Apps Hungarian / Plain debate through the eyes of Niklaus Wirth...
Spolsky and Wirth
I'm sure that everyone knows about Joel Spolsky's recent argument for Apps Hungarian and how .NET has it wrong in demanding Plain Notation (i.e. no variable prefixes).
It occurred to me that Niklaus Wirth would probably be spinning in his retirement chair wondering if he should come out of retirement for one last blog entry: "Why all you programmers of C type languages have it all wrong".
Extra Strong Types
Niklaus Wirth invented Pascal, Modula(2) and Oberon (and other languages) and while I've never used them in anger, from the work I have done in Modula-2 it seems that Wirth really believed in having types based on real world concepts rather than functional ability.
By this I mean that if you have a variable that holds money then I think Wirth would argue that you should create a Money type to hold it, and if you also have some variables that store percentages then you need a Percent type also. Most Java programmers (including me) would probably just use a float or an int, most of the time.
Joel argued that Apps Hungarian allows you to see the difference between a web-safe string and a non-web-safe string. Wirth would argue that if you created the type WebUnsafeString then the compiler would do all the work for you. There would be no need for the code to "look right" because it would not compile if it was wrong.
And in this I am dead with Wirth and not with Spolsky. It is better to make the code "right by proof" than "right by inspection". Code that is "right by inspection" can only be right while the inspectors are perfect and the code is unchanged.
So maybe it would be good if we could have some types that represented web safe strings and have the compiler check that only these types were output to the web. Just how to do this might be the subject of another blog entry. But I'm going to gloss over it in a hand-waving "this is not the issue to debate" kind of way for now.
I did something similar in a recent project where we wanted to make sure that all user visible strings were internationalized, so we created a special type and wherever we could we used that type in our interfaces to force lazy programmers to do it the Right Way.
Finality and Immutability
BUT this is where we run into the problem of immutable strings. In Java, String is immutable, and that means it must be final, and that means that your WebSafeString can't inherit from String so it must contain String, which is a bit of a pain.
And this got me thinking; what if String was not final - Well that would blow the security model because you could pass a CrackedString to some security sensitive procedure which assumed strings were immutable and the CrackedString would change.
But what if we also made all of the methods of string final and kept all the members private? Then string would always function in the same way. Things that inherited from String would still not be able to alter strings after they were checked, and the actions of any String function would go unchanged, so String would still be immutable. But you would be allowed to create sub-classes of string (like WebSafeString or InternationalizedString) that helped with type safety.
I'm sure I must have missed something? Can we really make Strings non-final without losing immutability?
And remind me to blog about how Strings are not actually immutable anyway.
(Updated to tidy a heading)