Overloaded constructors vs. Object initializations

[=?Utf-8?B?QW5kcmVhcw==?=]

Hi,

I would like to get some thoughts on Overloaded constructors vs. Object
initializations. Assuming that the class supports a default constructor, is
there any reason to include overloaded constructors when you are able to use
object initialization? I see a point, to provide the overloads, if you are
developing framework code that might support the need to run ontop of 2.x
but if you are writing a sealed application / know you are only going to
deploy on 3.x or higher, then the need doesn't seem as apparent to me.
..Andreas

[Pavel Minaev]

On Aug 14, 3:48*pm, Andreas <[e-mail]:

Hi,

I would like to get some thoughts on Overloaded constructors vs. Object
initializations. Assuming that the class supports a default constructor, is
there any reason to include overloaded constructors when you are able to use
object initialization?

Yes, when your object is immutable - then all your properties will be
readonly, and an object initializer cannot be used. And even for
mutable objects, there can be properties which should only be
initialized once when the object is created, and not changed
afterwards - e.g. Dictionary<,>.Comparer

[=?Utf-8?B?QW5kcmVhcw==?=]

I would like to get some thoughts on Overloaded constructors vs. Object

initializations. Assuming that the class supports a default constructor, is
there any reason to include overloaded constructors when you are able to use
object initialization?

Yes, when your object is immutable - then all your properties will be
readonly, and an object initializer cannot be used. And even for
mutable objects, there can be properties which should only be
initialized once when the object is created, and not changed
afterwards - e.g. Dictionary<,>.Comparer

Yes, you are right. Maybe I should have been a bit more precise by saying
"other than when you design explicitly require the use of non-default
constructor". Many times overloaded constructors have been used to make
object initialization a bit more userfriendly and to provide cleaner code,
such as

public class Person
{
public Person()
{ }

public Person(string firstName, string lastName) : this(0, firstName,
lastName)
{ }

public Person(int age, string firstName, string lastName)
{
......
}
}

[Pavel Minaev]

On Aug 14, 5:03*pm, Andreas <[e-mail]:

Yes, you are right. Maybe I should have been a bit more precise by saying
"other than when you design explicitly require the use of non-default
constructor". Many times overloaded constructors have been used to make
object initialization a bit more userfriendly and to provide cleaner code

In that context, object initializers are clearly superior (more
readable as well, since property names are spelled out). Besides, with
a significant number of properties, you can't cover all permutations
anyway (I often see such half-hearted attempts in the BCL, where you
need, say, a combo of property #1+#3+#4, but you only get constructors
for #1+#2+#3 or #1+#2+#4).

[Bill McCarthy]

"Pavel Minaev" <in****@gmail.comwrote in message news:f0**********************************@e39g2000 hsf.googlegroups.com...

In that context, object initializers are clearly superior (more
readable as well, since property names are spelled out). Besides, with
a significant number of properties, you can't cover all permutations
anyway (I often see such half-hearted attempts in the BCL, where you
need, say, a combo of property #1+#3+#4, but you only get constructors
for #1+#2+#3 or #1+#2+#4).

Unless of course you have support for optional parameters, then it is very easy to have a single constructor, and also makes it easy for objects to then have a concept of "dirty" or changed after initialization.

[Pavel Minaev]

On Aug 14, 5:25*pm, "Bill McCarthy" <[e-mail]:

"Pavel Minaev" <[e-mail] in messagenews:f0**********************************@e 39g2000hsf.googlegroups.com...

In that context, object initializers are clearly superior (more
readable as well, since property names are spelled out). Besides, with
a significant number of properties, you can't cover all permutations
anyway (I often see such half-hearted attempts in the BCL, where you
need, say, a combo of property #1+#3+#4, but you only get constructors
for #1+#2+#3 or #1+#2+#4).

Unless of course you have support for optional parameters, then it is very easy to have a single constructor, and also makes it easy for objects to then have a concept of "dirty" or changed after initialization. *

Well, CLS doesn't support optional parameters in general (so if VB
guys want to make libraries that are usable from C# and other .NET
languages, they can forget about Optional).

Also, when you have 3+ properties to initialize, constructor calls
become rather unreadable when there is no named argument support in a
language, because you don't know which argument corresponds to which
property.

[qglyirnyfgfo]

Yes, when your object is immutable - then all your properties will be

readonly, and an object initializer cannot be used. And even for
mutable objects, there can be properties which should only be
initialized once when the object is created, and not changed
afterwards - e.g. Dictionary<,>.Comparer

I guess technically you don’t really need constructors at all, they
are just there to make life simpler.

For example, in your “Dictionary<,>.Comparer” example, you could allow
a user to set the “Comparer” property using object initialization at
any time, but you will have to add some more logic to throw an error
if the user tries to set the “Comparer” property once the object is in
a state where changing the value of the property would cause
problems....... phiuuuu, that can get ugly!

So I would say that constructors exist not because they are necessary
but because they can make your code simpler and more robust.

I realize that this point is obvious and I am sure you already knew
this. I am just giving my 2 cent to the original poster.

Cheers!

[Bill McCarthy]

"Pavel Minaev" <in****@gmail.comwrote in message
news:4c**********************************@k30g2000 hse.googlegroups.com...

>

>Unless of course you have support for optional parameters, then it is
very easy to have
a single constructor, and also makes it easy for objects to then have a
concept of "dirty" or changed after initialization.

Well, CLS doesn't support optional parameters in general (so if VB
guys want to make libraries that are usable from C# and other .NET
languages, they can forget about Optional).

CLS does not specify anything about Optional parameters. That is they are
neither compliant or non compliant. Optional parameters are not variable
length parameter lists, rather they are compiler trickery. The compiler
reads from the list and adds the indicated default values for you if you
don't include the parameter when calling the method. Today, all CLS
languages can use methods that have optional arguments, but either the code
has to specify all parameters all the compiler fill in the gaps for you.

Also, when you have 3+ properties to initialize, constructor calls
become rather unreadable when there is no named argument support in a
language, because you don't know which argument corresponds to which
property.

Right. Named arguments is an important part of support for optional
parameters.
BTW: Pavel,would you mine changing your post encoding to none or mime rather
than Printed Quotable. Hard to reply and have who said what clear ;)

[Pavel Minaev]

On Aug 14, 7:10*pm, "Bill McCarthy" <[e-mail]:

CLS does not specify anything about Optional parameters. *That is they are
neither compliant or non compliant. *Optional parameters are not variable
length parameter lists, rather they are compiler trickery. *The compiler
reads from the list and adds the indicated default values for you if you
don't include the parameter when calling the method. *Today, all CLS
languages can use methods that have optional arguments, but either the code
has to specify all parameters all the compiler fill in the gaps for you.

Well, optional parameters that you have to specify in the call hardly
count as "optional", don't they? ;)

What I meant is that CLS does not specify any standard protocol for
optional parameters (or indeed the existence of such facility in
general), and therefore you can't expect any other language to treat
the parameters as optional - thus defeating their purpose.

Right. Named arguments is an important part of support for optional
parameters.

I would argue that named arguments are quite useful even on their own
- a method call with many parameters is much more readable when they
are explicitly named in the call.

BTW: Pavel,would you mine changing your post encoding to none or mime rather
than Printed Quotable. * Hard to reply and have who said what clear ;)

I'm reading and posting via Google Groups, so I don't think it's
something under my control, unfortunately.

[Bill McCarthy]

"Pavel Minaev" <in****@gmail.comwrote in message
news:5b**********************************@59g2000h sb.googlegroups.com...
On Aug 14, 7:10 pm, "Bill McCarthy" <[e-mail]:

>CLS does not specify anything about Optional parameters. That is they are
neither compliant or non compliant. Optional parameters are not variable
length parameter lists, rather they are compiler trickery. The compiler
reads from the list and adds the indicated default values for you if you
don't include the parameter when calling the method. Today, all CLS
languages can use methods that have optional arguments, but either the
code
has to specify all parameters all the compiler fill in the gaps for you.

Well, optional parameters that you have to specify in the call hardly
count as "optional", don't they? ;)

Sure, but that doesn't stop people susing them, much like doing VSTO stuff
in C# today

>
What I meant is that CLS does not specify any standard protocol for
optional parameters (or indeed the existence of such facility in
general), and therefore you can't expect any other language to treat
the parameters as optional - thus defeating their purpose.

CLS doesn't, but CLI does, specifically partition II section 15.4 and
15.4.1.4. Really, it's a bit like adding support for UInt32 as an
intrinsic CIL, except that is actually prohibited by CLS. ;)

>Right. Named arguments is an important part of support for optional
parameters.

I would argue that named arguments are quite useful even on their own
- a method call with many parameters is much more readable when they
are explicitly named in the call.

Yep (with moderation <g>)

>BTW: Pavel,would you mine changing your post encoding to none or mime
rather
than Printed Quotable. Hard to reply and have who said what clear ;)

I'm reading and posting via Google Groups, so I don't think it's
something under my control, unfortunately.

Ah okay. Maybe I need a better newsreader then ;)

[Pavel Minaev]

On Aug 14, 8:35*pm, "Bill McCarthy" <[e-mail]:

Well, optional parameters that you have to specify in the call hardly
count as "optional", don't they? ;)

Sure, but that doesn't stop people susing them, much like doing VSTO stuff
in C# today

Ouch... that brings back some very unpleasant memories, of 10+ ref
arguments for each call (none of which actually needed the "ref")...

What I meant is that CLS does not specify any standard protocol for
optional parameters (or indeed the existence of such facility in
general), and therefore you can't expect any other language to treat
the parameters as optional - thus defeating their purpose.

CLS doesn't, but CLI does, specifically partition II section 15.4 and
15.4.1.4. * *Really, it's a bit like adding support for UInt32 as an
intrinsic CIL, except that is actually prohibited by CLS. *;)

Thanks for the pointer, I didn't know CLI actually covered that. I
stand corrected.

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Pavel Minaev wrote:

On Aug 14, 7:10 pm, "Bill McCarthy" <[e-mail]:

>CLS does not specify anything about Optional parameters. That is they are
neither compliant or non compliant. Optional parameters are not variable
length parameter lists, rather they are compiler trickery. The compiler
reads from the list and adds the indicated default values for you if you
don't include the parameter when calling the method. Today, all CLS
languages can use methods that have optional arguments, but either the code
has to specify all parameters all the compiler fill in the gaps for you.

Well, optional parameters that you have to specify in the call hardly
count as "optional", don't they? ;)

What I meant is that CLS does not specify any standard protocol for
optional parameters (or indeed the existence of such facility in
general), and therefore you can't expect any other language to treat
the parameters as optional - thus defeating their purpose.

I think you are talking about optional arguments in the executed
code while Bill is talking about optional arguments in the source
code that are handled by the compiler.

Two different things. They solve the same problem. But in the context
of language interop, they are completely different.

Arne

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Pavel Minaev wrote:

On Aug 14, 5:25 pm, "Bill McCarthy" <[e-mail]:

>"Pavel Minaev" <[e-mail] in messagenews:f0**********************************@e 39g2000hsf.googlegroups.com...

>>In that context, object initializers are clearly superior (more
readable as well, since property names are spelled out). Besides, with
a significant number of properties, you can't cover all permutations
anyway (I often see such half-hearted attempts in the BCL, where you
need, say, a combo of property #1+#3+#4, but you only get constructors
for #1+#2+#3 or #1+#2+#4).

Unless of course you have support for optional parameters, then it is very easy to have a single constructor, and also makes it easy for objects to then have a concept of "dirty" or changed after initialization.

Well, CLS doesn't support optional parameters in general (so if VB
guys want to make libraries that are usable from C# and other .NET
languages, they can forget about Optional).

Also, when you have 3+ properties to initialize, constructor calls
become rather unreadable when there is no named argument support in a
language, because you don't know which argument corresponds to which
property.

There could be some clues in what the arguments are.

Arne

[Pavel Minaev]

On Aug 15, 4:42*am, Arne Vajhøj <[e-mail]:

I think you are talking about optional arguments in the executed
code while Bill is talking about optional arguments in the source
code that are handled by the compiler.

No, we both were talking about the latter. I did not realise that the
facility to mark parameters as optional was actually specified at the
CLI level.