473,695 Members | 3,309 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

[Proposal] Named and Optional Parameters with Default Values

I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)

so here we go..

To make things simpler and better readable I'd make all default parameters
named parameters so that you can decide for yourself which one to pass and
which not, rather than relying on massively overlaoded methods which
hopefully provide the best overload for you, for example the Image.DrawImage
method has 20 overloads.

I propose a syntax like the following:

public void Open(string path, AccessMode mode = AccessMode.Read ,
int bufferSize=1024 )
{
// ...
}

As you can see, path is a regular parameter which cannot be omitted, whereas
Mode and BufferSize provide default values and can be omitted when calling
the method.
Named parameters can only be declared behind all regular parameters and if
you have params parameters (variable parameterlist) is must be declared at
the end of the parameterlist. Although you can omit the named parameters if
you pass them they should appear in the same order as they were declared for
better readability.

You could call the example method like the following:

Open("text.txt" , $mode=AccessMod e.Write, $bufferSize=512 );
Open("text.txt" , $bufferSize=512 );
Open("text.txt" , $mode=AccessMod e.Write);
Open("text.txt" );

Note that an $ sign has to appear before all named parameter so that you
have no naming conflicts with other variables in the callers context.

Additionally there can not be more that one method with the same name and
the same regular parameters to avoid ambiguity, so:

Foo(int i, string a="");
Foo(int i, double f=1.0f);

Would not be allowed because the call Foo(100) could not be resolved.

How will it work?
----------------------------

the following method:

public void Open(string path, AccessMode mode = AccessMode.Read , int
bufferSize=1024 )
{
// ...
}

would generate the following code:

public struct OpenParams
{
public AccessMode mode;
public int bufferSize;

// because we cannot have parameterless ctors in structs
public static OpenParams DefaultValues
{
get{
OpenParams instance = new OpenParams();
instance.mode = AccessMode.Read ;
instance.buffer Size=1024;
return instance;
}
}
}

public void Open(string path, ref OpenParams parms)
{
// ...
}

and the call:

Open("text.txt" , $bufferSize=512 );

is compiled as:

OpenParams parms = OpenParams.Defa ultValues;
parms.bufferSiz e=512;
Open("text.txt" , ref parms);
So what do you think? Is it just another stupid idea or may it be worth the
effort and valueable for csharp programmers?

Jun 9 '06 #1
14 3266
I like it.

"cody" <de********@gmx .de> wrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..
I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)

so here we go..

To make things simpler and better readable I'd make all default parameters
named parameters so that you can decide for yourself which one to pass and
which not, rather than relying on massively overlaoded methods which
hopefully provide the best overload for you, for example the
Image.DrawImage
method has 20 overloads.

I propose a syntax like the following:

public void Open(string path, AccessMode mode = AccessMode.Read ,
int bufferSize=1024 )
{
// ...
}

As you can see, path is a regular parameter which cannot be omitted,
whereas
Mode and BufferSize provide default values and can be omitted when calling
the method.
Named parameters can only be declared behind all regular parameters and if
you have params parameters (variable parameterlist) is must be declared at
the end of the parameterlist. Although you can omit the named parameters
if
you pass them they should appear in the same order as they were declared
for
better readability.

You could call the example method like the following:

Open("text.txt" , $mode=AccessMod e.Write, $bufferSize=512 );
Open("text.txt" , $bufferSize=512 );
Open("text.txt" , $mode=AccessMod e.Write);
Open("text.txt" );

Note that an $ sign has to appear before all named parameter so that you
have no naming conflicts with other variables in the callers context.

Additionally there can not be more that one method with the same name and
the same regular parameters to avoid ambiguity, so:

Foo(int i, string a="");
Foo(int i, double f=1.0f);

Would not be allowed because the call Foo(100) could not be resolved.

How will it work?
----------------------------

the following method:

public void Open(string path, AccessMode mode = AccessMode.Read , int
bufferSize=1024 )
{
// ...
}

would generate the following code:

public struct OpenParams
{
public AccessMode mode;
public int bufferSize;

// because we cannot have parameterless ctors in structs
public static OpenParams DefaultValues
{
get{
OpenParams instance = new OpenParams();
instance.mode = AccessMode.Read ;
instance.buffer Size=1024;
return instance;
}
}
}

public void Open(string path, ref OpenParams parms)
{
// ...
}

and the call:

Open("text.txt" , $bufferSize=512 );

is compiled as:

OpenParams parms = OpenParams.Defa ultValues;
parms.bufferSiz e=512;
Open("text.txt" , ref parms);
So what do you think? Is it just another stupid idea or may it be worth
the effort and valueable for csharp programmers?

Jun 9 '06 #2
It's obvious you put a lot of thought into your proposal, but personally I'm
against optional parameters. Given that we have overloading in .NET, I
don't believe that optional parameters should have been carried over to
VB.NET much less that they should now be added to C#. Yes, there may be
situations where a method has several overloads. But the signature of those
overloads give additional information that could be lost or at least
obscured if optional parameters were used.

Say you have a method with five parameters --- A, B, C, D, E -- where D and
E are not required or where default values are OK. In this case, the idea
of optional parameters makes sense. But what if you have a situation where
you have odd combinations of those five parameters that must be used? For
example, you might have two versions of a method, one which accepts
parameters A, D, and E, and another which accepts A, B, and C. Using
overloading, you'd obviously use two overloaded methods. There'd be no
ambiguity about which combinations of the five parameters were valid.
Whereas if you tried to use optional parameters to design a single method,
you'd have to make B, C, D, and E optional. But there'd be no way to tell
what parameters were optional in which context.

Could optional parameters be used responsibly by programmers who knew to
avoid this issue? Sure. But why bother introducing an alternative when the
requirement is so elegantly handled by overloading? So you get an
occasional method that has several overloads. So what. There may be a lot
of them, but at least you know that they represent every valid combination
of parameters rather than having to guess it. For me, the option of making
the language more complex isn't worth the "benefit" of eliminating
superoverloaded methods.

Regards,

- Mitchell S. Honnert
"cody" <de********@gmx .de> wrote in message
news:%2******** ********@TK2MSF TNGP04.phx.gbl. ..
I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)

so here we go..

To make things simpler and better readable I'd make all default parameters
named parameters so that you can decide for yourself which one to pass and
which not, rather than relying on massively overlaoded methods which
hopefully provide the best overload for you, for example the
Image.DrawImage
method has 20 overloads.

I propose a syntax like the following:

public void Open(string path, AccessMode mode = AccessMode.Read ,
int bufferSize=1024 )
{
// ...
}

As you can see, path is a regular parameter which cannot be omitted,
whereas
Mode and BufferSize provide default values and can be omitted when calling
the method.
Named parameters can only be declared behind all regular parameters and if
you have params parameters (variable parameterlist) is must be declared at
the end of the parameterlist. Although you can omit the named parameters
if
you pass them they should appear in the same order as they were declared
for
better readability.

You could call the example method like the following:

Open("text.txt" , $mode=AccessMod e.Write, $bufferSize=512 );
Open("text.txt" , $bufferSize=512 );
Open("text.txt" , $mode=AccessMod e.Write);
Open("text.txt" );

Note that an $ sign has to appear before all named parameter so that you
have no naming conflicts with other variables in the callers context.

Additionally there can not be more that one method with the same name and
the same regular parameters to avoid ambiguity, so:

Foo(int i, string a="");
Foo(int i, double f=1.0f);

Would not be allowed because the call Foo(100) could not be resolved.

How will it work?
----------------------------

the following method:

public void Open(string path, AccessMode mode = AccessMode.Read , int
bufferSize=1024 )
{
// ...
}

would generate the following code:

public struct OpenParams
{
public AccessMode mode;
public int bufferSize;

// because we cannot have parameterless ctors in structs
public static OpenParams DefaultValues
{
get{
OpenParams instance = new OpenParams();
instance.mode = AccessMode.Read ;
instance.buffer Size=1024;
return instance;
}
}
}

public void Open(string path, ref OpenParams parms)
{
// ...
}

and the call:

Open("text.txt" , $bufferSize=512 );

is compiled as:

OpenParams parms = OpenParams.Defa ultValues;
parms.bufferSiz e=512;
Open("text.txt" , ref parms);
So what do you think? Is it just another stupid idea or may it be worth
the effort and valueable for csharp programmers?

Jun 9 '06 #3
> It's obvious you put a lot of thought into your proposal, but personally
I'm against optional parameters. Given that we have overloading in .NET,
I don't believe that optional parameters should have been carried over to
VB.NET much less that they should now be added to C#.
And my opinion is that a good language should not reqire the programmer to
duplicate a methods declaration lots of times to provide optional
parameters. Also the xml docs always have to be duplicated.
Also, when having lots of parameters a language should not rely on the
correct order of parameters but instead givt the ability to pass arguments
by their name to make the code cleaner and easier to read.
no one can guess what a call to Graphics.DrawIm age with its tail if
parameters does without having to read the documentation.
Say you have a method with five parameters --- A, B, C, D, E -- where D
and E are not required or where default values are OK. In this case, the
idea of optional parameters makes sense. But what if you have a situation
where you have odd combinations of those five parameters that must be
used? For example, you might have two versions of a method, one which
accepts parameters A, D, and E, and another which accepts A, B, and C.
Using overloading, you'd obviously use two overloaded methods.


Sure, in the case where optional arguments exclude each other, you *have* to
use two different methods, this is no cure for every disease :)

I tried hard and experimented a bit with the 30 existing overloads of
Graphics.DrawIm age and noted that with optional parameters the number of
overloads can be reduced to 12:

Graphics.DrawIm age (Image, Point)
Graphics.DrawIm age (Image, PointF)
Graphics.DrawIm age (Image, Rectangle, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, RectangleF, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Int32, Int32, Int32, Int32)
Graphics.DrawIm age (Image, Int32, Int32, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, Single, Single)
Graphics.DrawIm age (Image, Point[], Rectangle, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, PointF[], RectangleF, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, Rectangle, Int32, Int32, Int32, Int32,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)
Graphics.DrawIm age (Image, Rectangle, Single, Single, Single, Single,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)

This is not as good as I expected but it would make client code much cleaner
and you can decide which parameter to leave out instead of relying the
appropriate overload to exist which does not cover every case (What if I
want to pass DrawImageAbort but not ImageAttributes or the GraphicsUnit?
What if I want to pass position of the image with Point then I cannot pass
any other parameter just because there is no overload for that).
Jun 10 '06 #4
"cody" <de********@gmx .de> wrote in message
news:uP******** ******@TK2MSFTN GP02.phx.gbl...
It's obvious you put a lot of thought into your proposal, but personally
I'm against optional parameters. Given that we have overloading in .NET,
I don't believe that optional parameters should have been carried over to
VB.NET much less that they should now be added to C#.
And my opinion is that a good language should not reqire the programmer to
duplicate a methods declaration lots of times to provide optional
parameters.

Ah, but the different overloads are not duplications. They are giving extra
information that might otherwise be lost or obscured if optional parameters
were used. Each overload is telling the user "Hey, this particular
combination of parameters is valid. If you want to pass in a default value,
that's your business."
Also the xml docs always have to be duplicated. I believe this to be a limitation of the documentation tool -- that you
can't give a description at the method level instead of the overload
level -- rather than a limitation of the language.
Also, when having lots of parameters a language should not rely on the
correct order of parameters but instead givt the ability to pass arguments
by their name to make the code cleaner and easier to read. Personally, I don't see this as a big deal either way. I can see a case for
named parameters, but I don't think their inseperable from the concept of
optional parameters.
no one can guess what a call to Graphics.DrawIm age with its tail if
parameters does without having to read the documentation.

I don't think this is true, at least not as a principle that can be applied
to the concept of overloading. Again, with overloading there may be several
overloads you have to scroll through, but there is a definitive list of
allowable parameter combinations which can be used. In fact,I think the use
of optional parameters would *increase* the chance of having to look at the
documentation because they would more likely hide these valid combinations.
"OK, I remember that A is required and the rest are optional. But can I
call the method with just A, E, and C? I don't know! There's no way to
tell from just the signatures!"
Say you have a method with five parameters --- A, B, C, D, E -- where D
and E are not required or where default values are OK. In this case, the
idea of optional parameters makes sense. But what if you have a
situation where you have odd combinations of those five parameters that
must be used? For example, you might have two versions of a method, one
which accepts parameters A, D, and E, and another which accepts A, B, and
C. Using overloading, you'd obviously use two overloaded methods.


Sure, in the case where optional arguments exclude each other, you *have*
to use two different methods, this is no cure for every disease :)

I tried hard and experimented a bit with the 30 existing overloads of
Graphics.DrawIm age and noted that with optional parameters the number of
overloads can be reduced to 12:

Graphics.DrawIm age (Image, Point)
Graphics.DrawIm age (Image, PointF)
Graphics.DrawIm age (Image, Rectangle, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, RectangleF, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Int32, Int32, Int32, Int32)
Graphics.DrawIm age (Image, Int32, Int32, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, Single, Single)
Graphics.DrawIm age (Image, Point[], Rectangle, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, PointF[], RectangleF, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, Rectangle, Int32, Int32, Int32, Int32,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)
Graphics.DrawIm age (Image, Rectangle, Single, Single, Single, Single,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)

This is not as good as I expected but it would make client code much
cleaner and you can decide which parameter to leave out instead of relying
the appropriate overload to exist which does not cover every case (What if
I want to pass DrawImageAbort but not ImageAttributes or the GraphicsUnit?
What if I want to pass position of the image with Point then I cannot pass
any other parameter just because there is no overload for that).

I admit that with methods that have many parameters, the number of overloads
increases greatly. But in my opinion, these superoverloaded methods are
rare enough that it does not warrant the drastic measure of introducing
optional parameters to C#. In your statement above, you are using the word
"rely" in a negative sense; to me it's a positive thing. I can rely on the
designer of a method to show me the allowable combination of parameters by
using the overloaded methods. I don't have to look in the documentation; I
can see it just by the method definition alone. If not having optional
parameters give me this assurance, but in rare cases, I don't have the exact
overload I need, then so be it. I'm OK with that.

- Mitchell S. Honnert
Jun 12 '06 #5
Mitchell S. Honnert wrote:
"cody" <de********@gmx .de> wrote in message
news:uP******** ******@TK2MSFTN GP02.phx.gbl...
It's obvious you put a lot of thought into your proposal, but personally
I'm against optional parameters. Given that we have overloading in .NET,
I don't believe that optional parameters should have been carried over to
VB.NET much less that they should now be added to C#. And my opinion is that a good language should not require the programmer to
duplicate a methods declaration lots of times to provide optional
parameters.

Ah, but the different overloads are not duplications. They are giving extra
information that might otherwise be lost or obscured if optional parameters
were used. Each overload is telling the user "Hey, this particular
combination of parameters is valid. If you want to pass in a default value,
that's your business."


As I said, if using optional parameters *all* combinations *must* be
valid. if not, you have to split the method into multiple overloads as I
showed with the DrawImage example (the Int32,Int32,Int 32,Int32 overload
is certainly not compatible with the Point or Rectangle overload - the
question also is whether these overloads are useful, IMO they complicate
the method more than they help - is it better readable to pass 4 x int
instead of one rectangle - certainly not (at least not if the method
already has too much parameters)).

Thus, with optional parameters you can rely on the fact that all
combinations are valid. And nothing get obscured, intellisense should
also show you the optional parameters.

Additional you can actually see the default values and do not have to
guess it (or look in the documentation). Currently if you use
string.Compare( string, string) vs. string.Compare( string, string, bool)
you do not see which default value the bool value is when omitting it at
the call, with built in optional parameters, intellisense can show it to
you.

Also the xml docs always have to be duplicated.

I believe this to be a limitation of the documentation tool -- that you
can't give a description at the method level instead of the overload
level -- rather than a limitation of the language.
Also, when having lots of parameters a language should not rely on the
correct order of parameters but instead givt the ability to pass arguments
by their name to make the code cleaner and easier to read.

Personally, I don't see this as a big deal either way. I can see a case for
named parameters, but I don't think their inseperable from the concept of
optional parameters.
no one can guess what a call to Graphics.DrawIm age with its tail if
parameters does without having to read the documentation.

I don't think this is true, at least not as a principle that can be applied
to the concept of overloading. Again, with overloading there may be several
overloads you have to scroll through, but there is a definitive list of
allowable parameter combinations which can be used. In fact,I think the use
of optional parameters would *increase* the chance of having to look at the
documentation because they would more likely hide these valid combinations.
"OK, I remember that A is required and the rest are optional. But can I
call the method with just A, E, and C? I don't know! There's no way to
tell from just the signatures!"
Say you have a method with five parameters --- A, B, C, D, E -- where D
and E are not required or where default values are OK. In this case, the
idea of optional parameters makes sense. But what if you have a
situation where you have odd combinations of those five parameters that
must be used? For example, you might have two versions of a method, one
which accepts parameters A, D, and E, and another which accepts A, B, and
C. Using overloading, you'd obviously use two overloaded methods.

Sure, in the case where optional arguments exclude each other, you *have*
to use two different methods, this is no cure for every disease :)

I tried hard and experimented a bit with the 30 existing overloads of
Graphics.DrawIm age and noted that with optional parameters the number of
overloads can be reduced to 12:

Graphics.DrawIm age (Image, Point)
Graphics.DrawIm age (Image, PointF)
Graphics.DrawIm age (Image, Rectangle, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, RectangleF, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Int32, Int32, Int32, Int32)
Graphics.DrawIm age (Image, Int32, Int32, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, Single, Single)
Graphics.DrawIm age (Image, Point[], Rectangle, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, PointF[], RectangleF, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, Rectangle, Int32, Int32, Int32, Int32,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)
Graphics.DrawIm age (Image, Rectangle, Single, Single, Single, Single,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)

This is not as good as I expected but it would make client code much
cleaner and you can decide which parameter to leave out instead of relying
the appropriate overload to exist which does not cover every case (What if
I want to pass DrawImageAbort but not ImageAttributes or the GraphicsUnit?
What if I want to pass position of the image with Point then I cannot pass
any other parameter just because there is no overload for that).

I admit that with methods that have many parameters, the number of overloads
increases greatly. But in my opinion, these superoverloaded methods are
rare enough that it does not warrant the drastic measure of introducing
optional parameters to C#. In your statement above, you are using the word
"rely" in a negative sense; to me it's a positive thing. I can rely on the
designer of a method to show me the allowable combination of parameters by
using the overloaded methods. I don't have to look in the documentation; I
can see it just by the method definition alone. If not having optional
parameters give me this assurance, but in rare cases, I don't have the exact
overload I need, then so be it. I'm OK with that.

- Mitchell S. Honnert

Jun 12 '06 #6
cody wrote:
I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)

<snip/>
So what do you think? Is it just another stupid idea or may it be worth the
effort and valueable for csharp programmers?


I really respect the effort that you have put into this post, but I
think (based on my experience) that this is not a simple feature at all.

Let's take a look at your slightly extended example:

class Base
{
public virtual void Open(string path,
AccessMode mode = AccessMode.Read ,
int bufferSize=1024 )
{
// ...
}
}
// derived class
class Derived
{
public virtual void Open(string path,
AccessMode mode = AccessMode.Writ e,
int bufferSize=1024 )
{
// ...
}
}
Base b = new Derived();
b.Open("..");

Is it open for read or for write? And this is just a starter! I just
have to dig in my dark memories of the C++ world... Just think about
shadowing a method with "new", overloaded methods that are scattered
over an inheritance hierarchy, abstract methods and last but not least
interfaces. It is sure possible to define a meaningful behavior for all
of it (it was possible in C++), but this isn't a simple and easy feature
than anymore. Actually it is one of the pitfalls that Scott Meyers
mentions in his famous Effective C++ books.

Maintenance/Feature development (Keeping alive the features you have and
add new ones ) is the most difficult part in a software project.
Maintenance is done by reading and interpreting code so that you can
extend or refactor it. Features like this in the best case add an
unnecessary difficulty to it, because now I have to take default
variables into account.
Cheers,
Andy
Jun 12 '06 #7
> Thus, with optional parameters you can rely on the fact that all
combinations are valid. And nothing get obscured, intellisense should also
show you the optional parameters. This is true in the examples you've given, but in my experience with
VB6\VB.NET optional programmers are not used to reduce the overloads from
about 30 to 12, but to reduce them from about three to one. In other words,
even when creating three overloads would make sense -- because you only
really have three valid combinations of your parameters -- the programmer
would use optional parameters "because it's easier". This is such an awful
scenario that I personally wouldn't want to bring over that corruption from
the VB world. (For the record, VB.NET is my language of choice. I just
think optional parameters in VB.NET is an example of where MS pandered too
much to the old school VB6 developers.) Would C# programmers "know better"?
Probably, but it's not worth the risk.
Additional you can actually see the default values and do not have to
guess it (or look in the documentation). This is a really good point. I'll admit to having had to look up a default
value of some of the sparser overloads, especially constructors. However,
for me this wouldn't sway my opinion that optional parameters wouldn't be
worth the drawbacks.

- Mitchell S. Honnert

"cody" <de********@gmx .de> wrote in message
news:OO******** ******@TK2MSFTN GP03.phx.gbl... Mitchell S. Honnert wrote:
"cody" <de********@gmx .de> wrote in message
news:uP******** ******@TK2MSFTN GP02.phx.gbl...
It's obvious you put a lot of thought into your proposal, but
personally I'm against optional parameters. Given that we have
overloading in .NET, I don't believe that optional parameters should
have been carried over to VB.NET much less that they should now be
added to C#.
And my opinion is that a good language should not require the programmer
to duplicate a methods declaration lots of times to provide optional
parameters.

Ah, but the different overloads are not duplications. They are giving
extra information that might otherwise be lost or obscured if optional
parameters were used. Each overload is telling the user "Hey, this
particular combination of parameters is valid. If you want to pass in a
default value, that's your business."


As I said, if using optional parameters *all* combinations *must* be
valid. if not, you have to split the method into multiple overloads as I
showed with the DrawImage example (the Int32,Int32,Int 32,Int32 overload is
certainly not compatible with the Point or Rectangle overload - the
question also is whether these overloads are useful, IMO they complicate
the method more than they help - is it better readable to pass 4 x int
instead of one rectangle - certainly not (at least not if the method
already has too much parameters)).

Thus, with optional parameters you can rely on the fact that all
combinations are valid. And nothing get obscured, intellisense should also
show you the optional parameters.

Additional you can actually see the default values and do not have to
guess it (or look in the documentation). Currently if you use
string.Compare( string, string) vs. string.Compare( string, string, bool)
you do not see which default value the bool value is when omitting it at
the call, with built in optional parameters, intellisense can show it to
you.

Also the xml docs always have to be duplicated.

I believe this to be a limitation of the documentation tool -- that you
can't give a description at the method level instead of the overload
level -- rather than a limitation of the language.
Also, when having lots of parameters a language should not rely on the
correct order of parameters but instead givt the ability to pass
arguments by their name to make the code cleaner and easier to read.

Personally, I don't see this as a big deal either way. I can see a case
for named parameters, but I don't think their inseperable from the
concept of optional parameters.
no one can guess what a call to Graphics.DrawIm age with its tail if
parameters does without having to read the documentation.

I don't think this is true, at least not as a principle that can be
applied to the concept of overloading. Again, with overloading there may
be several overloads you have to scroll through, but there is a
definitive list of allowable parameter combinations which can be used.
In fact,I think the use of optional parameters would *increase* the
chance of having to look at the documentation because they would more
likely hide these valid combinations. "OK, I remember that A is required
and the rest are optional. But can I call the method with just A, E, and
C? I don't know! There's no way to tell from just the signatures!"
Say you have a method with five parameters --- A, B, C, D, E -- where D
and E are not required or where default values are OK. In this case,
the idea of optional parameters makes sense. But what if you have a
situation where you have odd combinations of those five parameters that
must be used? For example, you might have two versions of a method,
one which accepts parameters A, D, and E, and another which accepts A,
B, and C. Using overloading, you'd obviously use two overloaded
methods.
Sure, in the case where optional arguments exclude each other, you
*have* to use two different methods, this is no cure for every disease
:)

I tried hard and experimented a bit with the 30 existing overloads of
Graphics.DrawIm age and noted that with optional parameters the number of
overloads can be reduced to 12:

Graphics.DrawIm age (Image, Point)
Graphics.DrawIm age (Image, PointF)
Graphics.DrawIm age (Image, Rectangle, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, RectangleF, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Int32, Int32, Int32, Int32)
Graphics.DrawIm age (Image, Int32, Int32, Rectangle, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, RectangleF, GraphicsUnit)
Graphics.DrawIm age (Image, Single, Single, Single, Single)
Graphics.DrawIm age (Image, Point[], Rectangle, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, PointF[], RectangleF, GraphicsUnit,
ImageAttributes , Graphics.DrawIm ageAbort, Int32)
Graphics.DrawIm age (Image, Rectangle, Int32, Int32, Int32, Int32,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)
Graphics.DrawIm age (Image, Rectangle, Single, Single, Single, Single,
GraphicsUnit, ImageAttributes , Graphics.DrawIm ageAbort, IntPtr)

This is not as good as I expected but it would make client code much
cleaner and you can decide which parameter to leave out instead of
relying the appropriate overload to exist which does not cover every
case (What if I want to pass DrawImageAbort but not ImageAttributes or
the GraphicsUnit? What if I want to pass position of the image with
Point then I cannot pass any other parameter just because there is no
overload for that).

I admit that with methods that have many parameters, the number of
overloads increases greatly. But in my opinion, these superoverloaded
methods are rare enough that it does not warrant the drastic measure of
introducing optional parameters to C#. In your statement above, you are
using the word "rely" in a negative sense; to me it's a positive thing.
I can rely on the designer of a method to show me the allowable
combination of parameters by using the overloaded methods. I don't have
to look in the documentation; I can see it just by the method definition
alone. If not having optional parameters give me this assurance, but in
rare cases, I don't have the exact overload I need, then so be it. I'm
OK with that.

- Mitchell S. Honnert

Jun 12 '06 #8

cody wrote:
I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)


You posted this idea back in February 2005:

http://groups.google.com/group/micro...38375540a95f34

and I posted a link to a whiteboard discussion with Anders Hejlsberg in
which he points out the problems with the approach you're suggesting:

http://msdn.microsoft.com/msdntv/epi...h/manifest.xml

Briefly, the difficulty is that implementing default arguments in the
compiler, rather than the CLR, creates versioning problems: if you
release a new version of your commercial DLL with new (let's say
corrected) defaults for some of your parameters, your callers don't get
the new defaults unless they recompile their client code.

I agree with his objection: if there's going to be defaulting, I would
want it so that the defaults are picked up from the called assembly at
runtime, not compiled into the caller's assembly at compile time. That
way you can update a DLL and pick up new defaults without recompiling
all client code.

This could be done by the compiler, but it would be clumsy: it would
involve trolling the called assembly on every method call looking for
attributes attached to the called method, and getting default values
from there. Very slow and very ugly.

If I recall, this was also Anders' objection to run-time resolution of
defaults, which would resolve the problems I outlined above: it would
add unacceptable overhead to method calls. Can't be sure, though: I
haven't watched the video in over a year.

I made a suggestion to MSDN Feedback regarding the XML documentation
thing, but I can no longer find my suggestion in their reworked
feedback site:

http://connect.microsoft.com/feedbac...spx?SiteID=210

In that same whiteboard discussion (and again at PDC'05), suggestions
were made to Anders about having the compiler allow documentation
sharing between overloads or on inheritance. He seemed to like the
idea, but I've never seen it received with much enthusiasm by the C#
team, and I with it were. Repeating documentation every time I inherit
/ overload is a pain, and it's time I would prefer to use doing
something more productive, like posting to newsgroups. :-)

Jun 12 '06 #9

Bruce Wood wrote:
cody wrote:
I got a similar idea a couple of months ago, but now this one will require
no change to the clr, is relatively easy to implement and would be a great
addition to C# 3.0 :)


You posted this idea back in February 2005:

http://groups.google.com/group/micro...38375540a95f34

and I posted a link to a whiteboard discussion with Anders Hejlsberg in
which he points out the problems with the approach you're suggesting:

http://msdn.microsoft.com/msdntv/epi...h/manifest.xml


Oh, my bad, my bad. I didn't properly read your post. My only excuse is
that I have a cold today and my brain is all foggy. Let me tackle this
one again.

There are still problems here, but they're not as severe as the ones I
outlined. For example, it's sort of counterintuitiv e that if you have
default values for parameters, and you release a DLL in which some
methods have new parameters but they have defaults, you still have to
recompile client code in order that it be compatible (otherwise the
MethodParams struct that you pass in would not be the right size). It's
not the end of the world, but addressing it would require changes to
the CLR.

Another way to do what you're thinking of is to have the compiler
quietly use nullable types where parameters are declared optional, but
this involves boxing and unboxing, even if it's behind the scenes, and
still carries with it the problem that adding new parameters, even if
they have defaults, would require recompilation of all client code.

I don't really see any elegant way to handle this without changes to
the CLR and the way that parameters are placed on the stack, so that
called methods would have some built-in notion of "argument not
supplied" which would occur if the caller signaled that it wished to
omit an argument, or if the number of arguments falls short of the
required number.

Anyway, as I remarked in February, I'd much rather just see a way to
share XML doc between overloads / overrides. I consider that a much
bigger pain in the butt than the multiple-overload thing.

Jun 12 '06 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
3002
by: Anne van Kesteren | last post by:
Ok, here it goes. Originally I submitted this proposal to www-style. Since I don't get feedback there, I think I missed a few (maybe a lot) of points. Proposal: <http://lists.w3.org/Archives/Public/www-style/2003Nov/0096.html> (for some strange reason I can't post to that list myself) The first point I missed was of course that CSS3UI is not planning to do anything with FIELDSET and LEGEND
13
2513
by: William Ryan | last post by:
I just picked up a copy of John Robbins' debugging book and started to look at disassembled code. Anyway, I hate optional Parameters in VB, but I was checking them out to see what IL is created. I've done this before with Modules, and saw that <gasp> they behave just like sealed classes with only static members. Anyway, it looks like Optional Parameters are nothing but a way to tell the compiler to write some overloads for you. So, in...
18
3449
by: Peter Hardy | last post by:
Hi Guys, Can I use named parameters in C# Methods. i.e doFoo(fname="do", lname="Foo"); Cheers, Pete
8
3039
by: cody | last post by:
Why doesn't C# allow default parameters for methods? An argument against I hear often is that the default parameters would have to be hardbaken into the assembly, but why? The Jit can take care of this, if the code is jitted the "push xyz" instructions of the actual default values can be inserted. To make things simpler and better readable I'd make all default parameters named parameters so that you can decide for yourself why one to...
17
2155
by: Ben R. | last post by:
I'm reading about attribute classes and specifically, named versus positional parameters. Was this implimented instead of multiple constructors for flexibility or is there another reason I'm missing? -Ben
5
7416
by: Imran Aziz | last post by:
Hello All, I am new to C# , how can I delare parameters to a function as optional, and also how are default values assigned ? consider the function public String myFunc(String thisisOptional, String OptWithDefaultValue) { }
12
2291
by: Nick Hounsome | last post by:
Can anyone tell me what the rational is for not supporting optional arguments. It is obviously a trivial thing to implement and, since C++ has them, I would not expect them to be omitted without a good reason.
12
2663
by: pamelafluente | last post by:
Hi guys, In the past I have used several time optional parameters in my function. But Now I am more inclined to think that they are more dangerous than useful, and probably better to be avoided. I'd like to hear your various opinions on this matter.
7
7056
by: jamesclose | last post by:
My problem is this (apologies if this is a little long ... hang in there): I can define a function in VB.NET with optional parameters that wraps a SQL procedure: Sub Test(Optional ByVal Arg1 As Integer = 0, _ Optional ByVal Arg2 As Integer = 0, _ Optional ByVal Arg3 As Integer = 0) ' Call my SQL proc with the same signature
0
8640
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8582
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9001
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8860
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
1
6498
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
5841
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
4587
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2281
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
1984
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.