The VB behavior is by design - I believe the idea is that before any code in the derived class runs (including the initialization of member variables, which in
vb can use non static base members), the base class is fully constructed. Of course, you can still work around that by calling overriden members in the
base constructor, although that sounds like something I'd personally avoid - the base class is invoking code in the derived class that will be run before the
derived class's constructor has finalized initialization, how sure can you be that whoever is writing the derived class has assumed that that code can be run
before the constructor?
(I mean, I wouldn't trust myself to remember in six months that a method that I override from the base can't assume initialization is finished :) )
The approach In C#'s case is somewhat safer, but it does imply that you can't use base class's data members to initalize the derived class's data
members on the declaration.
Alex
MS VB QA
--------------------
From: "twawsico" <tw******@hotmail.com>
Newsgroups: microsoft.public.dotnet.languages.vb
Subject: Inherited class behavior vs. C#
Date: 20 Mar 2005 07:26:25 -0800
Organization: http://groups.google.com
Lines: 28
Message-ID: <11**********************@z14g2000cwz.googlegroups .com>
NNTP-Posting-Host: 24.0.20.109
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1111332390 16099 127.0.0.1 (20 Mar 2005 15:26:30 GMT)
X-Complaints-To: gr**********@google.com
NNTP-Posting-Date: Sun, 20 Mar 2005 15:26:30 +0000 (UTC)
User-Agent: G2/0.2
Complaints-To: gr**********@google.com
Injection-Info: z14g2000cwz.googlegroups.com; posting-host=24.0.20.109;
posting-account=wCp07Q0AAABPQrPQRaSXkjnLdzxjpO6y
Path: TK2MSFTNGXA02.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSF TNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-online.de!news-
spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnew s.google.com!z14g2000cwz.googlegroups.com!not-for-mailXref: TK2MSFTNGXA02.phx.gbl microsoft.public.dotnet.languages.vb:266377
X-Tomcat-NG: microsoft.public.dotnet.languages.vb
I ran into this while converting some DX C# code to VB.NET (VS 2003),
and I'm just curious as to whether this is intended behavior (and if
so, where might I read up on it) or more of a bug.
This involves creating a New instance of a derived class that inherits
a base class. In C#, private member vars in the derived class ( e.g.
private MySimpleObject MyObject = new MySimpleObject();) are
instantiated immediately when the the calling code attempts to
instantiate the derived class. Order of execution then goes
DerivedClass::New() method, then (before executing code within
DerivedClass::New) to BaseClass:New().
The problem/difference is that, using the same classes in VB.NET, the
order of execution changes. The private member var object in the
Derived class does not get instantiated until AFTER the execution
returns from BaseClass.New() and begins the actual code within
DerivedClass.New().
I can implement a workaround (this actually causes errors with the DX
code due to an overridden method which expects the object to have been
instantiated by that point). But is this an *intended* difference
between the two languages?
If my explanation of the problem isn't clear, please advise and I'll
post some sample code. It's easy to reproduce.
Thanks in advance.
