Actually the field initializer of log will run before the base class ctor -
I guess precisely because of this situation (well this is true in C# but not
in VB.NET). 

I can see the point of not disallowing the behaviour as its quite
permissible for me to seal a class so I might have inheritance in my
implementation that results in a sealed class at the end - and in this class
I specialize the construction.

Personally I wouldn't do it as I think it is a serious maintenance issue in
any application architecture - we end up with behaviour that is not
*obvious* and obvious visible behaviour is always easier to maintain.

Regards

Richard Blewett
DevelopMentor

-----Original Message-----
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] On Behalf Of Stefan Holdermans
Sent: 19 June 2003 21:42
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Partially constructed objects in C#

Robert,

>This is a bad example, but let's say we had the following 
>code-- why wouldn't this be a valid use of a virtual method in 
>a constructor?

Because as you publish your Fred class in a library, users of your library
can provide a class BamBam as follows:

  public class BamBam : Fred {
    private string log = "log:";

    public override void LogMessage(string msg) {
    // DANGER: Fred's constructor call this method before
    // BamBam's field log is initialized
      if (msg != null) {
        this.log += "\n";
        if this.log += msg;
      }
    }
  }

The comment says it all.

(Maybe I'm wrong, but isn't this where this discussion is about? Can someone
please confirm? Either Rob or myself is missing the point completely.)

Regards,

Stefan


>-----Original Message-----
>From: [EMAIL PROTECTED] 
>[mailto:[EMAIL PROTECTED] On Behalf 
>Of Streno, Robert
>Sent: Thursday, June 19, 2003 9:30 PM
>To: 'Moderated discussion of advanced .NET topics.'
>Subject: RE: [ADVANCED-DOTNET] Partially constructed objects in C#
>
>
>I'm not sure I see the harm in providing a virtual function to 
>be called from my constructor if it provides for "optional" 
>constructor functionality.
>
>This is a bad example, but let's say we had the following 
>code-- why wouldn't this be a valid use of a virtual method in 
>a constructor?
>
>public class Fred
>{
>        public Fred()
>        {
>                LogMessage("Constructor");
>      }
>
>      protected virtual void LogMessage(string strMessage)
>      {
>                System.Console.WriteLine(strMessage);
>        }
>}
>
>public class Pebbles : Fred
>{
>        //Override LogMessage function to write to debug 
>instead of Console
>        public override void LogMessage(string strMessage)
>        {
>                System.Environment.Debug.WriteLine(strMessage);
>        }
>}
>
>
>-----Original Message-----
>From: Stefan Holdermans [mailto:[EMAIL PROTECTED]
>Sent: Thursday, June 19, 2003 3:11 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [ADVANCED-DOTNET] Partially constructed objects in C#
>
>
>John,
>
>>You missed his point.
>
>Then, exactly, what is his point?
>
>>So break the init into critical and non-critical, with the 
>non-critical 
>>being virtal.
>
>That won't do the trick though. Calling the virtual method 
>from the constructor is not reliable. That's why FxCorp issues 
>a warning. The method call being critical or non-critical to 
>construction does not matter here.
>
>I think, as a rule, it's best not to call virtual methods from 
>constructors. Hence, the FxCorp rule. If you disagree, please 
>let me know why... Maybe it is me missing the point.
>
>Furthermore, if you want initialization to be customizable, 
>you should introduce some idiom for it. Perhaps a Initialize 
>method this is *not* called from the constructor. (This leaves 
>it up to the client to call it---and I can tell why you're not 
>happy with that, but the life of a programmer is not always a 
>walk in park, you know... Just think of it as the 
>construction/initialization complement of Dispose. Maybe you 
>should define an IDispoable-like interface for it: 
>IInitializable or something...)
>
>Cheers,
>
>Stefan
>

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 10/06/2003
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.489 / Virus Database: 288 - Release Date: 10/06/2003
 

Reply via email to