I had to try this: FxCopy 1.2.1 does detect this as a warning: Virtual methods defined on the class should not be called from constructors. If a derived class has overridden the method, the derived class version will be called (before the derived class constructor is called).
-----Original Message----- From: Streno, Robert [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 5:57 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Partially constructed objects in C# I love discussions of this nature! :) I guess what it comes down to is that "you get what you pay for." As an architect, I would not allow my developers to do this. However, as an architect, I may need to use this to provide specific functionality. If I did (and the case would be rare), I would certainly provide developers with strict guidelines, and I would make sure that the implementation was as safe as possible (and designed to fail gracefully the first time they tried something that didn't work). -R -----Original Message----- From: Stefan Holdermans [mailto:[EMAIL PROTECTED] Sent: Friday, June 20, 2003 5:45 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Partially constructed objects in C# 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 > >
