constructor in beta 2

[Gijs Wassink]

I found some samples (TreadStaticVariables) in beta 2, that implements a contructor
whithout the
line MyBase.new

Is this a typo or is this a change in beta 2.

regards

[Bill McCarthy]

Hi Gijs,

The MyBase.New is superfulous. Adding it has no effect in the constructor.
Regardless of whether you have it in the code or not, the first call made in
the constructor is to initiate the base class.



"Gijs Wassink" <g.wassink@tref.nl> wrote in message
news:3b31b257$1@news.devx.com...
>
> I found some samples (TreadStaticVariables) in beta 2, that implements a
contructor
> whithout the
> line MyBase.new
>
> Is this a typo or is this a change in beta 2.
>
> regards
>

[Franklin E. Vargas]

Sad but true. What this means is that you can not control the invocation
of MyBase.New. The framework forces new to be called at the first statement
in the constructor. I was hoping they would allow more flexibility. Even
if you overload the constructor, the overloaded version invokes Base.New()
first. Perhaps Microsoft intends to provide this flexibility in future releases.


"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote:
>Hi Gijs,
>
>The MyBase.New is superfulous. Adding it has no effect in the constructor.
>Regardless of whether you have it in the code or not, the first call made
in
>the constructor is to initiate the base class.
>
>
>
>"Gijs Wassink" <g.wassink@tref.nl> wrote in message
>news:3b31b257$1@news.devx.com...
>>
>> I found some samples (TreadStaticVariables) in beta 2, that implements
a
>contructor
>> whithout the
>> line MyBase.new
>>
>> Is this a typo or is this a change in beta 2.
>>
>> regards
>>
>
>

[Bill McCarthy]

Hi Franklin,

yep, indeed it is sad. I suppose they just tried to make it more idiot proof.
Strange thing is, they don't seem to be using that in their own code !! Yep,
they actually do things on the derived class instance fields etc in some of
their code before calling the base constructor. Makes sense especially when
writing controls that have windows. Pity they don't give us the same
flexibility as they demand for themselves !


"Franklin E. Vargas" <franklin.vargas@thegarden.com> wrote in message
news:3b320db9@news.devx.com...
>
> Sad but true. What this means is that you can not control the invocation
> of MyBase.New. The framework forces new to be called at the first statement
> in the constructor. I was hoping they would allow more flexibility. Even
> if you overload the constructor, the overloaded version invokes Base.New()
> first. Perhaps Microsoft intends to provide this flexibility in future
releases.
>
>
> "Bill McCarthy" <bill_mcc@iprimus.com.au> wrote:
> >Hi Gijs,
> >
> >The MyBase.New is superfulous. Adding it has no effect in the constructor.
> >Regardless of whether you have it in the code or not, the first call made
> in
> >the constructor is to initiate the base class.
> >
> >
> >
> >"Gijs Wassink" <g.wassink@tref.nl> wrote in message
> >news:3b31b257$1@news.devx.com...
> >>
> >> I found some samples (TreadStaticVariables) in beta 2, that implements
> a
> >contructor
> >> whithout the
> >> line MyBase.new
> >>
> >> Is this a typo or is this a change in beta 2.
> >>
> >> regards
> >>
> >
> >
>

[Mattias Sjögren]

Bill,

>yep, indeed it is sad.

Why is it so sad? Have you gotten into a situation where you really
had to do things before the base class was properly initialized?


>Strange thing is, they don't seem to be using that in their own code !! Yep,
>they actually do things on the derived class instance fields etc in some of
>their code before calling the base constructor.

In which classes does this happen?


>Makes sense especially when writing controls that have windows.

I don't see why that would make sense.


Mattias

====================================
Mattias Sjögren - mattias @ mvps.org
http://www.msjogren.net/dotnet/

CodeHound - The Software Developer's Search Engine
http://www.codehound.com

[Bill McCarthy]

Hi Mattias,

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:3b323d83.163453914@news.devx.com...
> Bill,
>
> >yep, indeed it is sad.
>
> Why is it so sad? Have you gotten into a situation where you really
> had to do things before the base class was properly initialized?
>

yep.

>
> >Strange thing is, they don't seem to be using that in their own code !!
Yep,
> >they actually do things on the derived class instance fields etc in some of
> >their code before calling the base constructor.
>
> In which classes does this happen?
>

most/many of the windows.forms classes for example.

>
> >Makes sense especially when writing controls that have windows.
>
> I don't see why that would make sense.
>

well if the base class creates a window in it's constructor, it would save
some effort if the information was provided to it to start of with, rather
than having to recreate a window.

[Mattias Sjögren]

Hi Bill,

>> Why is it so sad? Have you gotten into a situation where you really
>> had to do things before the base class was properly initialized?
>>
>
>yep.

Can you tell us some more details?


>> In which classes does this happen?
>>
>
>most/many of the windows.forms classes for example.

I looked at a some of them, but couldn't find any that fits the
description. Can you give me a name? I just find it hard to believe,
since I recall hearing that Windows Forms are built with C#, and you
can't do this in C# either.

Perhaps you're getting confused by the field initialization that takes
place in the C# constructors before the base constructor is called.
That is perfectly safe.


>well if the base class creates a window in it's constructor, it would save
>some effort if the information was provided to it to start of with, rather
>than having to recreate a window.

That's what parameterized constructors are for. Just pass any
information the base class needs as parameters to one of its ctors.


Mattias

====================================
Mattias Sjögren - mattias @ mvps.org

[Bill McCarthy]

Hi Mattias,

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:3b32901e.184601502@news.devx.com...
> >
> >yep.
>
> Can you tell us some more details?
>

yep


> >
> >most/many of the windows.forms classes for example.
>
> I looked at a some of them, but couldn't find any that fits the
> description. Can you give me a name? I just find it hard to believe,
> since I recall hearing that Windows Forms are built with C#, and you
> can't do this in C# either.
>
> Perhaps you're getting confused by the field initialization that takes
> place in the C# constructors before the base constructor is called.
> That is perfectly safe.
>

Uhm, must be my accent. I did say "they actually do things on the derived
class instance fields etc in some of their code before calling the base
constructor" So yes I was referring to field initialisation, instance fields
not static fields, and fields of the derived class, not the base class.

This is something VB.NET does not do, and does not allow !! This is the
issue. Should we be forced to have to work in C# ??

Take for instance this simple class heirarchy :

Public Class foo
Public Sub New()
Console.WriteLine(Number)
End Sub
Public Overridable ReadOnly Property Number() As Int32
Get
Return 5
End Get
End Property
End Class

Public Class boo : Inherits foo
Private myNumber As Int32 = 2
Public Overrides ReadOnly Property Number() As Int32
Get
Return myNumber
End Get
End Property
End Class

Now if you do Dim b as New boo(), in VB.NET the console output will be 0. The
same code converted to C# will output 2 !!

So when it comes to window sytles etc, then all the default flags are
interpreted as zero or False etc.


>
> That's what parameterized constructors are for. Just pass any
> information the base class needs as parameters to one of its ctors.
>

Oh come of it. First, the winForms designer will not create a parameterized
constructor with a dozen or so arguements. It calls the default constructor
and then sets the properties.
Secondly, do you really think that having a constructor with a dozen or so
parameters is good design ? Eg TreeView.New(showLines,
showPlusMinus,showRootLines, hideSelection, hotTracking, FullRowSelect,
labelEdit, scrollable, sorted, checkboxes, indent, itemheight, etc)
Thirdly, how do you ensure that that constructor gets called before the base
constructor gets called in VB.NET ? You simply can't. The base constructor
gets called before you have a chance to initialise any local fields. So having
a parameterised constructor still does not address the issue in the first
place.

[Jatin]

Hi,
Why cant one put the initialization code in the constructor of the class
So you put this line in the constructor of base class: myNumber = 2

That should take care of initializing the variable when the base class is
instantiated.


"Bill McCarthy" <bill_mcc@iprimus.com.au> wrote:
>Hi Mattias,
>
>"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
>news:3b32901e.184601502@news.devx.com...
>> >
>> >yep.
>>
>> Can you tell us some more details?
>>
>
>yep
>
>
>> >
>> >most/many of the windows.forms classes for example.
>>
>> I looked at a some of them, but couldn't find any that fits the
>> description. Can you give me a name? I just find it hard to believe,
>> since I recall hearing that Windows Forms are built with C#, and you
>> can't do this in C# either.
>>
>> Perhaps you're getting confused by the field initialization that takes
>> place in the C# constructors before the base constructor is called.
>> That is perfectly safe.
>>
>
>Uhm, must be my accent. I did say "they actually do things on the derived
>class instance fields etc in some of their code before calling the base
>constructor" So yes I was referring to field initialisation, instance fields
>not static fields, and fields of the derived class, not the base class.
>
>This is something VB.NET does not do, and does not allow !! This is the
>issue. Should we be forced to have to work in C# ??
>
>Take for instance this simple class heirarchy :
>
>Public Class foo
> Public Sub New()
> Console.WriteLine(Number)
> End Sub
> Public Overridable ReadOnly Property Number() As Int32
> Get
> Return 5
> End Get
> End Property
>End Class
>
>Public Class boo : Inherits foo
> Private myNumber As Int32 = 2
> Public Overrides ReadOnly Property Number() As Int32
> Get
> Return myNumber
> End Get
> End Property
>End Class
>
>Now if you do Dim b as New boo(), in VB.NET the console output will be 0.
The
>same code converted to C# will output 2 !!
>
>So when it comes to window sytles etc, then all the default flags are
>interpreted as zero or False etc.
>
>
>>
>> That's what parameterized constructors are for. Just pass any
>> information the base class needs as parameters to one of its ctors.
>>
>
>Oh come of it. First, the winForms designer will not create a parameterized
>constructor with a dozen or so arguements. It calls the default constructor
>and then sets the properties.
>Secondly, do you really think that having a constructor with a dozen or
so
>parameters is good design ? Eg TreeView.New(showLines,
>showPlusMinus,showRootLines, hideSelection, hotTracking, FullRowSelect,
>labelEdit, scrollable, sorted, checkboxes, indent, itemheight, etc)
>Thirdly, how do you ensure that that constructor gets called before the
base
>constructor gets called in VB.NET ? You simply can't. The base constructor
>gets called before you have a chance to initialise any local fields. So
having
>a parameterised constructor still does not address the issue in the first
>place.
>
>
>
>
>
>

[Kathleen Dollard]

Jatin,

Why do you think that will alter the output that Bill displayed?

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Mattias Sjögren]

Hi Bill!

>Uhm, must be my accent.

Nah, more likely me posting at 2:30 AM, that's usually not very smart
:-)


>I did say "they actually do things on the derived
>class instance fields etc in some of their code before calling the base
>constructor" So yes I was referring to field initialisation, instance fields
>not static fields, and fields of the derived class, not the base class.

Right, sorry.


>This is something VB.NET does not do, and does not allow !! This is the
>issue. Should we be forced to have to work in C# ??

I'm still not convinced that this really is a problem. The C# way is
different, yes, but I can't say it's more (or less) correct than the
VB way.


>Now if you do Dim b as New boo(), in VB.NET the console output will be 0. The
>same code converted to C# will output 2 !!

Yeah, that's what might happen when you're calling virtual methods
from constructors. That's usually not a good idea IMO. It can cause
weird and unexpected behaviour, such as

http://discuss.develop.com/archives/...OTNET&P=R27361

So the thing to keep in mind is that when instance field
initialization happens is language specific (and we're not just
dealing with C# and VB.NET here). Assuming that it happens at a
specific time is asking for trouble. :-)

For example, parts of the code you posted looks like this when
translated to C#

public class boo : foo
{
private int myNumber = 2;

public override int Number
{
get { return myNumber; }
}
}

But then imagine that you for some reason have to move the
initialization to a constructor

....
private int myNumber;

public boo()
{
myNumber = 2;
}
....

Now the output changes to 0, just like in the VB case.


>Oh come of it. First, the winForms designer will not create a parameterized
>constructor with a dozen or so arguements. It calls the default constructor
>and then sets the properties.
>Secondly, do you really think that having a constructor with a dozen or so
>parameters is good design ?

OK, what I wrote about parameterized ctors was more for the general
case. Of course it's not always the best solution.

IIRC, Windows Forms doesn't create a control's window handle in the
constructor. So using the default constructor, and then setting
properties afterwards, shouldn't cause any handle recreation.


Mattias

====================================
Mattias Sjögren - mattias @ mvps.org

[Bill McCarthy]

Hi Mattias,

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:3b35f4a0.13853950@news.devx.com...
>
> Nah, more likely me posting at 2:30 AM, that's usually not very smart
> :-)
>

<g>

>
> >This is something VB.NET does not do, and does not allow !! This is the
> >issue. Should we be forced to have to work in C# ??
>
> I'm still not convinced that this really is a problem. The C# way is
> different, yes, but I can't say it's more (or less) correct than the
> VB way.
>

True. But given that's theway winForms works, then we have to assume the C#
way is correct <g>

>
> Yeah, that's what might happen when you're calling virtual methods
> from constructors. That's usually not a good idea IMO. It can cause
> weird and unexpected behaviour, such as
>
> http://discuss.develop.com/archives/...OTNET&P=R27361
>

<bg> yep, I remember that bug. You use to have to test to see if sender is
nothing. But I think that has been fixed. They now call suspend layout in the
base control's constructor. They still get and set the rect though


> So the thing to keep in mind is that when instance field
> initialization happens is language specific (and we're not just
> dealing with C# and VB.NET here). Assuming that it happens at a
> specific time is asking for trouble. :-)
>
> For example, parts of the code you posted looks like this when
> translated to C#
>
> public class boo : foo
> {
> private int myNumber = 2;
>
> public override int Number
> {
> get { return myNumber; }
> }
> }
>
> But then imagine that you for some reason have to move the
> initialization to a constructor
>
> ...
> private int myNumber;
>
> public boo()
> {
> myNumber = 2;
> }
> ...
>
> Now the output changes to 0, just like in the VB case.
>


yep. That was what I was showing <bg>. The second case is *all* vb.net can do,
whereas in C# you have the choice.

>
> OK, what I wrote about parameterized ctors was more for the general
> case. Of course it's not always the best solution.
>

yep.

> IIRC, Windows Forms doesn't create a control's window handle in the
> constructor. So using the default constructor, and then setting
> properties afterwards, shouldn't cause any handle recreation.
>

Okay, my mistake. See I shouldn't post in the early hours either <bg>. Looks
like the window is actually initiated when added to the controls collection
(Me.Controls.Add (.....) ) But the windows.control constructor does call on my
createParams. It uses this info to adjust the control's rect. If I can't
supply it info about the non client areas, borders etc, then what's the point
of it calling on that in it's constructor. Seems like just duplication, as it
will need to do it all over again. So either that call is wasted, amounting to
jsut overhead, as the rect may need adjusting again, or there is reason to
give it the correct CreateParams structure first time round.

[Franklin E. Vargas]

Greetings!

This has certainly been a good exercise and it has led me to the following
conclusions. By the way by Framework Beta 2 is down and I am referring to
Beta 1 to make these comments.

1. The Framework employs more flexibility when it comes to constructing instances
and the base class. Framework Developers have more control of the order of
invocation of class constructors. VB forces this order in a particular way.

2. Whether this flexibility is required remains to be proven. It is likely
that this flexibility is optional as is usually the case and that Framework
developers, working mostly in non-VB languages, have made use of this flexibility
throughout the framework--especially in the handling of initialization and
the visual aspects of certain classes.

3. Assuming this flexibility is not required, we may then ask if it is convenient
to have. Is it more trouble than it is worth? Do Framework developers use
it simply because it is available to them or is it available to them because
they have found it very useful?

4. If VB.NET is meant to provide consistency by enforcing construction in
a particular way, this has not been done efficiently. It is unclear whether
we should use MyBase.New or not and how it should be used. Here are some
serious problems.

a. Let's say class1 has new and new(m as integer) as constructors, if class2
inherits from class1 and it does not re-declare the constructors, you get
the following error when using the integer argument constructor. "error
BC30057: Too many arguments to method 'Sub New()' in dim obj as Class2 =
new Class2(num)"

b. If you re-declare both constructors (without including the MyBase.new),
both constructors call Class1.new() without arguments instead of invoking
their respective constructor signatures.

c. I really dislike this error message: "error BC30282: A direct call to
a constructor is allowed only as the first statement in a constructor. MyBase.New(p)"

I have gone behind the mscorlib.dll to make these conclusions and found a
multitude of classes where instance constructions are arranged at will. However,
I have not studied any of the classes sufficiently to determine if they could
have been created better. Additionally, I have not investigated C#'s treatment
of this subject in enough detail.

[Mattias Sjögren]

Bill,

>yep. That was what I was showing <bg>. The second case is *all* vb.net can do,
>whereas in C# you have the choice.

Yeah, I know. My point was that depending on it being one way or the
other would be foolish, at least in components that can be used by
different client languages.


>But the windows.control constructor does call on my
>createParams. It uses this info to adjust the control's rect. If I can't
>supply it info about the non client areas, borders etc, then what's the point
>of it calling on that in it's constructor.

Good question - I'd love to hear an answer from Markbou or Chrisan.

In this particular case, can't you hava a shared CreateParams field
that you initialize with meaningful default values in a shared
constructor?


Mattias

====================================
Mattias Sjögren - mattias @ mvps.org

[Bill McCarthy]

Hi Mattias,

"Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message
news:3b37a4e9.5289896@news.devx.com...
>
> Yeah, I know. My point was that depending on it being one way or the
> other would be foolish, at least in components that can be used by
> different client languages.
>

LOL. I am so tempted to say "yeh, it looks like the winforms crew hasn't heard
of VB.NET" but I can't be that cruel <bgd&r>

>
> >But the windows.control constructor does call on my
> >createParams. It uses this info to adjust the control's rect. If I can't
> >supply it info about the non client areas, borders etc, then what's the
point
> >of it calling on that in it's constructor.
>
> Good question - I'd love to hear an answer from Markbou or Chrisan.
>

yep.

> In this particular case, can't you hava a shared CreateParams field
> that you initialize with meaningful default values in a shared
> constructor?
>

I could. I would also need a boolean flag to tell me if my fields have been
initiated. e.g.

Public Class MySuperControl
Shared Private mySharedCreateParams as CreateParams
Private blnHasBeenInitiated As Boolean

Public Sub New()
blnHasBeenInitiated = True
End Sub

Shared Public Sub New()
With mySharedCreateParams
.xxx = llll
......
End With
End Sub

Public Property CreateParams() as CreateParams
Get
If not blnHasBeenInitiated Then
return mySharedCreateParams
End If
'normal return of create params in here

End Get




But I don't like it. It is messy, it's more work. I think I'd rather just
compile the **** thing and manually edit the IL, moving the call to the base
constructor to after my field initializers.