Re: Readonly locals?
- From: Jeroen Mostert <jmostert@xxxxxxxxx>
- Date: Tue, 01 Jul 2008 00:46:37 +0200
Bob Powell [MVP] wrote:
You can simulate something like what you want with a property as shown below.Well, as far as I can tell your approach is "a nonsense". What advantage do you foresee from having a write-once property?
int _p;
bool _pset;
int P
{
get{return _p;}
set
{
if(!_pset)
{
_pset=true;
_p=value;
}
}
}
To expect this of the compiler for a field is, IMO, a nonsense.
The critical advantage from a read-only field comes from knowing that its value will be determined at construction time, and not changed afterwards. So:
private readonly int p;
public int P { get { return p; } }
Reasoning about P is now trivial; it will never change. You're free to cache it, share it, or provide alternate representations, without having to worry about keeping anything in sync. Threading issues disappear if you hand off copies, which you can safely do since you'll never have out-of-date copies. In short: immutability is a useful thing.
A write-once property is much less useful, because the implementer of the class still doesn't know exactly when the property will be written to, so the (limited) immutability is something you can hardly count on. That's not even taking into account that such a property is quite unintuitive to clients (whether internal or external).
A class should have access to its fields but allowing public access to fields breaks the rules of encapsulation so classes must provide properties.I'm not sure you understood the OP's meaning. He was talking about local *variables*, i.e.:
private int interestingMethod(int a, int b, int c) {
readonly int d = a * 24 + b / 3 + c; // Does not compile
...
// If it did, we could forget about some potential issues by knowing that d will never change
}
You can do this in Java with "final". You can't do it in C#. It would have been easy enough to add, but it just wasn't. It's one of those things.
What use is an immutable local variable, you ask? Well, what use is a *mutable* local variable? You'll often declare temporary variables that hold the value of some involved expression you don't want to retype (or one that really should be evaluated only once), but which are never changed afterwards. Reusing such a variable and assigning a different value is either a serious mistake or something that will make the code a whole lot harder to read (because after point X, your temporary variable suddenly means something different). If you could declare it readonly, you couldn't fall into this trap in the first place.
Immutable locals are also of use in refactoring. Transforming the code to a new form (preferrably one with smaller independent parts) by introducing or eliminating local variables is a lot safer if you can guarantee that a variable isn't assigned to halfway down the method, or modified by passing it as a ref parameter somewhere. Automated refactoring tools can help here, but if you don't have them (or they can't do what you want) compiler-enforced immutability can be quite useful.
A class should have enough knowledge of it's own internal workings to not break rules that it sets for itself.
But a class doesn't set rules or break them, the programmer does. This is the same as saying "the programmer should be infallible". The programmer should certainly be free to make their own life easier by preventing themselves from making mistakes in the first place.
This implies that the need for such a construct as an immutable orFunctional programming languages would disagree, as would the designers of LINQ. You are correct inasmuch as a language is not made any richer by providing a way for marking things immutable, but it is made more expressive, and this can benefit both programmer and compiler.
"set-once" local variable is superflouous.
--
J.
.
- Follow-Ups:
- Re: Readonly locals?
- From: Weeble
- Re: Readonly locals?
- From: Marc Gravell
- Re: Readonly locals?
- Prev by Date: Re: LINQ book
- Next by Date: Re: Readonly locals?
- Previous by thread: Re: Readonly locals?
- Next by thread: Re: Readonly locals?
- Index(es):
Relevant Pages
|
