http://msdn2.microsoft.com/en-US/library/ms229057(VS.80).aspx

* Do not assign instances of mutable types to read-only fields.

I would have to disagree with this "Field Design" guidelines...to an extent.

Example:

public class SomeClass {
    private NameValueCollection mCollection;
    public SomeClass() { mCollection = new NameValueCollection(); }
    public NameValueCollection Collection {
        get { return mCollection; }
    }
    public int CollectionCount()
    {
        return mCollection.Count;
    }
}

For the above (granted, there may be some errors as this is just off top of
my head), the CollectionCount method requires that the mCollection field be
set.  I expose the collection to the callee using a read-only property.  The
property returns the mutable type just as I want.  In a scenerio for my
example, the callee is allowed to change the internal collection values
(add/remove items to a list).  But, if the user was allowed to modify the
actual reference, they could set it to null which would cause other areas of
the class (the mCollection.Count) to throw NullReferenceException's.
Therefore, am I not correct that in this instance, the mutable type being
returned by a read-only field is an exception to the rule?

Thanks,
Mythran

Why does it need to be read only? Why not just have a get accessor? I
don't think there's any reason to this rule other than the fact that
"readonly mutable type" is misleading. Yes you can't change the
reference but readonly also should imply that you can't change the
value (and thus change things like the return from GetHashCode(), etc).

Hi,


You expose it using a get property, using this only assure that the
reference holded in the class will not change, on other words, if you are
holding a reference to instance A the callee can not make change it to
instance B.  IT DOES NOT assure that the instance itself cannot change its
state. If you want this the referenced class hasve to be inmutable ( like
string).

I will try to explain, but the language can be confused, feel free to
comment back if further clarification is needed.

A readonly field and a read-only property ( which only define a get ) has
nothing in common. They are two completely different concepts.

a readonly field is declared using the readonly  reserved word, this has two
implications:
1- a value should be assign in the spot    or in a constructor
2- after it's assigned you cannot change it.

If you assign a primitive type you have effectively blocked that value :

readonly int i=5;

has the effect that i will ALWAYS be 5.

A similar thing happens with a struct:

public struct S
{
public int i;
}

class C
{
  readonly S s = new S();

  void method1()
{
     s.i=4; //error
}

}


Now if the readonly is a referenced type, all the above change.

What you cannot change is the referenced instance, the member of the
instance can be changed at will:

public class S
{
public int i;
}

class C
{
  readonly S s = new S();

  void method1()
{
     s.i=4; //good now
    s = new S(); //error
}

}


hope this clarify it.
Let me know if not.

On 2006-04-20, Mythran <kip_potter@hotmail.comREMOVETRAIL> wrote:
Show quoteHide quoteThe guidelines you reference are distinguishing between fields and
properties.  In the above code, the property is readonly, while the
field is not, which is exactly what the guidelines suggest doing.

Show quoteHide quote

Getting Exception on Command Line Args, but works within IDE debug
Multi-line comments
Communication between forms
Datagrid binding problem
VS2005 - Passing NumericUpDown into a class method?
Legacy Connection Object - I need a new one
Editing Multiple DataGridViews
IE Privacy - DNS Problem - ASP.NET
security issues with an upgraded VB6 program
DX9 SDK (Feb 2006) / .NET 2.0