Set readonly in constructor of a derived class.

  • Thread starter Thread starter William Stacey
  • Start date Start date
W

William Stacey

I know the following is not allowed, but shouldn't it be? sharedObject is
part of Derived and should be able to be set in the constructor - no? tia

public abstract class Base1
{
protected readonly object sharedObject;

}
public class Derived : Base1
{

public Derived()
{
sharedObject = new object();
}

}
 
Hi William,

The readonly keyword is a modifier that you can use on fields. When a field
declaration includes a readonly modifier, assignments to the fields
introduced by the declaration can only occur as part of the declaration or
in a constructor in the same class.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is the link for detail information.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/
vclrfreadonlypg.asp

Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
 
William Stacey said:
I know the following is not allowed, but shouldn't it be? sharedObject is
part of Derived and should be able to be set in the constructor - no?
Click to expand...

<snip>

As well as the answer given by Peter, I'd also suggest that making any
fields non-private is at least *usually* a bad idea. It's not so bad
for throwaway classes, or perhaps nested classes that are only visible
to the enclosing class, but I'd steer away from using them elsewhere.
 
Thanks Peter. I understand the normal usage of readonly. However I am
asking a different question. As Derived inherits "sharedObject", and Base1
is abstract, isn't "sharedObject" a member of the Derived class? And if so,
why can't the *constructor in Derived set the value in its' constructor?
 
Thanks Jon. However that is not exactly why I asked the question. I posted
more explicit (hopefully) question to Peter in this thread.
 
William Stacey said:
Thanks Peter. I understand the normal usage of readonly. However I am
asking a different question. As Derived inherits "sharedObject", and Base1
is abstract, isn't "sharedObject" a member of the Derived class? And if so,
why can't the *constructor in Derived set the value in its' constructor?
Click to expand...

Well, it's a member of the derived class, but it's not *declared* in
the derived class, and as section 17.4.2 of the C# specification says:

<quote>
Direct assignments to readonly fields can only occur as part of that
declaration or in an instance constructor or static constructor in the
same class.
</quote>

Now, did you mean "why" as in "why doesn't the compiler allow it" or
"why" as in "why did the language designers choose to write the spec
that way"?

I'm not sure I see why the base class being abstract makes any
difference, to be honest - it's not like that means it can't have
constructors.
 
William,
In addition to Peter's & Jon's comments.

I don't think it should be allowed, as sharedObject belongs to Base1, Base1
knows the proper way to initialize the field. If Base1 wants to allow any
derived classes in having a say in initializing it, then Base1 should have a
constructor that allows or requires the derived classes to set it. This way
Base1's constructor cannot initialize it, then have a derived class's
constructor come along and 'trash' that initialization...

Something like:
public abstract class Base1
{
protected readonly object sharedObject;
Click to expand...

protected Base1(object sharedObject)
{
this.sharedObject = sharedObject;
}
}
Click to expand...

public class Derived : Base1
{
public Derived() : base(new object())
{
}
Click to expand...
}

The above has the added benefit of not allowing Derived to avoid
initializing the shared object. Of course Base1 could have overloaded
constructors that default sharedObject if that is appropriate.

Also I agree with Jon, sharedObject should be private, I would make a
protected Property that derived classes could use.

Hope this helps
Jay
 
Hi William,

I think the point of readonly is that the value can't be changed (ie it's
like const).
If derived classes could modify it, this wouldn't be true.



Regards,
Peter Huang
Microsoft Online Partner Support
Get Secure! www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

--------------------
From: "William Stacey" <[email protected]>
References: <[email protected]>
Click to expand...
Subject: Re: Set readonly in constructor of a derived class.
Date: Tue, 7 Oct 2003 05:01:26 -0400
Lines: 78
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.3790.0
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
Message-ID: <#7#[email protected]>
Newsgroups: microsoft.public.dotnet.languages.csharp
NNTP-Posting-Host: 66.188.59.114.bay.mi.chartermi.net 66.188.59.114
Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftngp13.phx.gbl
Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.languages.csharp:189475
X-Tomcat-NG: microsoft.public.dotnet.languages.csharp

Thanks Peter. I understand the normal usage of readonly. However I am
asking a different question. As Derived inherits "sharedObject", and Base1
is abstract, isn't "sharedObject" a member of the Derived class? And if so,
why can't the *constructor in Derived set the value in its' constructor?

--
William Stacey, MVP

Peter Huang said:
Hi William,

The readonly keyword is a modifier that you can use on fields. When a field
declaration includes a readonly modifier, assignments to the fields
introduced by the declaration can only occur as part of the declaration or
in a constructor in the same class.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Here is the link for detail information.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html
Click to expand...
/
Click to expand...
 
Also I agree with Jon, sharedObject should be private, I would make a
protected Property that derived classes could use.
Click to expand...

It is protected. If it was private, derived class would not have access to
it.
 
William,
If it was private, derived class would not have access to it.
Click to expand...
Exactly the reason I would make it private!! The field itself is an
implementation detail, derived classes should not be poking their noses into
an implementation detail of the base!

With a protected Property the derived classes would have access to the value
via the property. Because the property is Protected, external classes would
not see the value if that was the desired effect. If the field already has a
public property, then the derived classes can access the value via the
public property...

On a lesser note with the Property the details of how that field is stored
can change without modifying the derived classes...

Hope this helps
Jay
 
Agree with that and I get properties. Was done to demonstrate an idea
without complicating the thread and code with a seperate discusion on
properties (as this has fallen into) which has no bearing on what I was
trying to understand. Thanks Jay.
 
Back
Top