Hi Keith,
You can think of read-only as runtime constant & a const as compile constant.
A read-only(runtime constant) is usually a better choice than using a const(compile constant).
A const will give a slight performance gain, but nothing worth caring.
A const can only be used for primitive types(int, double, etc..)
Readonly can be any type, and can be used as instance constants.
Another advantage is readonly constants reference the readonly variable which are resolved at runtime.
Using a AutoCAD example if you have a library that uses P/Invoke and contains a constant like "acad.exe".
When you reference that library into a application and compile it the compiler creates IL that stores "acad.exe" directly in the assembly.
If you update the library to "accoremgd.dll" and distribute new library a application that was built with previous version will still use "acad.exe", and would require the application to be re-built to update the value.
If a read-only was used the application that references the new library would get the new value through the read-only variable which is evaluated at runtime and would use new value, without having to rebuild the application since it does not "bake-in" read-only constants into the assembly.
I had considered that, but I thought the people much smarter than me would just say "dumbass .. if you don't want it changed, then don't change it" ... building a construct into a programming language to handle idiots is idiotic.
I guess in a world where multiple programmers work on the same project it might be useful though.
I understand the nuance between "private const" and "private readonly" ... as a general rule I use constants a) where it is unlikely that the value will ever need to be changed during the lifecycle of the project; and b) where a value can be changed at design time to effect change in many places throughout the code base. (i.e. int const MAX_VAL = 1024;)
The issue I was wondering about was why would one declare a class variable both private and readonly. If you are using them as a replacement for constants, then I can see that, although, I would still just stick with constants where it is a better choice.
So, in essence why this:Code - C#: [Select]
public class Foo{ private readonly int _item; //What advantage does a readonly variable provide in this context? public Foo(int item) { _item = item; } }
instead of thisCode - C#: [Select]
public class Foo{ private int _item; //Is there an advantage to making this a readonly variable if it isn't going to be changed elsewhere in code? public Foo(int item) { _item = item; } }
I understand the nuance between "private const" and "private readonly" ... as a general rule I use constants a) where it is unlikely that the value will ever need to be changed during the lifecycle of the project; and b) where a value can be changed at design time to effect change in many places throughout the code base. (i.e. int const MAX_VAL = 1024;)
Changing from a field to a property breaks the contract (e.g. requires all referencing code to be recompiled). So when you have an interaction point with other classes - any public (and generally protected) member, you want to plan for future growth. Do so by always using properties.from http://stackoverflow.com/a/1180864/492 (same page)
Hijack! :-D From a code maintenance point of view you are better off using properties. See http://stackoverflow.com/questions/1180860/public-fields-versus-automatic-properties and especiallyQuoteChanging from a field to a property breaks the contract (e.g. requires all referencing code to be recompiled). So when you have an interaction point with other classes - any public (and generally protected) member, you want to plan for future growth. Do so by always using properties.from http://stackoverflow.com/a/1180864/492 (same page)
On the original topic, I avoid constants like the plague because the .NET C# compiler hardcodes them into their actual values, even in the calling assemblies.