Re: [ADVANCED-DOTNET] Partially constructed objects in C#

[Stephen Dunn]

This is exactly what the discussion is about.
The most important question (IMHO) is "When does BamBam become a fully
fledged 'object'"?
Since we have no control over the program flow from BamBam.ctor to
Fred.ctor, I would say that we have no control over our [BamBam] object and
hence the object is not really an object and shouldn't be treated as such by
anything, including the compiler, the run-time, or base classes(which know
nothing of the object anyway).

Cheers,

Steve


-----Original Message-----
From: Stefan Holdermans [mailto:[EMAIL PROTECTED]
Sent: 19 June 2003 21:42
To: [EMAIL PROTECTED]

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
>