Overloaded constructors

[cmay]

Can someone quick shed some light on this issue I am having?

I wanted to create 2 constructors for my object, one that takes an ID
value and one that takes a datarow.

If ID value is provided, it is going to get the info from the database
and populate itself. If a datarow is provided, then it will use the
row to populate itself.

So, I wanted to have the "by ID" function get a datarow from the
database, and then call the overloaded New function and pass in the
datarow, to keep all the logic in one place.
For example:

public sub New(ID as integer)
'Get Datarrow from DB
dim oRow as DataRow
call Me.New(oRow)
end sub

public sub New(Row as DataRow)
'Fill properties of class
end sub
Like that...
Now, I know that I can move the logic into another private method,
which is what I have done for a workaround, but is there a reason I am
not allowed to do this? Is this not a good way to work with overloaded
constructors?

[Chris Dunaway]

What do you mean you are not allowed to do that? Are you getting an
error message? In what way is it not working?

Instead of Me.New, I would recommend calling MyClass.New, MyClass being
a reserved keyword in VB.

[cmay]

I get the same compile error w/ Me., MyBase, and MyClass:

Constructor call is valid only as the first statement in an instance
constructor.

[alantolan]

You need to have the call to the other ctor be the first instruction -
you can't even have a declaration before it.
The best that I can think of is have a common routine that both call

Public sub new( _
id as integer _
)
Init(GetRow(id) )
end sub

Public sub new ( _
row as DataRow _
)
Init(row)
end sub

Private function GetRow( _
id as integer _
)
...
end function

Private sub Init( _
row as DataRow _
)
// all the code that was previously in the DataRow version of the
ctor
end sub
hth,
Alan.

[Mattias Sjögren]

FYI you can put the code that retrieves the DataRow given the ID in a
Shared method, and call it like this

Public Sub New(ID as integer)
MyClass.New(Get RowFromId(ID))
End Sub
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[cmay]

That is basically what I am doing now, just wanted to make sure I
wasn't missing something or doing it the wrong way.

[dfoster]

On 2005-08-29, cmay <cm**@walshgrou p.com> wrote:

Can someone quick shed some light on this issue I am having?

Now, I know that I can move the logic into another private method,
which is what I have done for a workaround, but is there a reason I am
not allowed to do this? Is this not a good way to work with overloaded
constructors?

To answer your second question first, I think using the overloaded
constructors with a private initialization function is indeed the perfect
way to work with constructors (Interestingly, using a shared function
to get the datarow as someone else suggested feels wrong to me, although
the two are basically equivalent).

For the first question, the reason you can't do the above is that when
you write a Sub New, the compiler puts in code to construct the base
class as the first line of the Sub New. IOW, what you're really trying
to do above is...

Public Sub New (id as Integer)
MyBase.New()
' do something
Dim row As New DataRow
Me.New(row)
End Sub

Public Sub New(row As DataRow)
MyBase.New()
' do something
End Sub

You see the problem. The base ctor is being called twice. Now, when
you chain constructors...

Public Sub New(id As Integer)
Me.New()
End Sub

Public Sub New()
MyBase.New() ' <-- The compiler puts in this call
End Sub

In this case, the compiler knows that it doesn't need to call the base
class ctor from New(id), because New() will call the base class, so
New(id) doesn't get the base class call. But the compiler only figures
this out if the very first line of Sub New is a call to another Sub New.
Anything else is a compiler error.

Technically, I suppose the compiler *could* be smarter than this, since
there's no inherent reason that your original code couldn't compile
and run fine. But this behavior has sort of become a standard across
multiple languages, and handling this differently would be a very tricky
problem for a compiler.

[cmay]

Thanks for the indepth answer.
Chris