Richard,
>Actually the field initializer of log will run before the base
>class ctor [...]
Well, you're right about that offcourse. I was making the example to simple.
I should have let the BamBam constructor take the log string as a parameter,
in order to show the danger, shouldn't I?
public class BamBam : Fred {
private string log;
public BamBam(string log) { this.log = log; }
public override void LogMessage(string msg) {
// DANGER: Fred's constructor calls this method before
// BamBam's constructor assigned to the field log
if (msg != null) {
this.log += "\n";
if this.log += msg;
}
}
}
Regards,
Stefan
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf
>Of Richard Blewett
>Sent: Friday, June 20, 2003 11:31 AM
>To: 'Moderated discussion of advanced .NET topics.'
>Subject: RE: [ADVANCED-DOTNET] Partially constructed objects in C#
>
>
>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
>
>
