Named parameters?

[Ben R.]

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

[Daniel O'Connell [C# MVP]]

"Ben R." <Be**@discussio ns.microsoft.co m> wrote in message
news:01******** *************** ***********@mic rosoft.com...

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?

It is flexibility more than anything else, I think. Considering the sets of
options an attribute has, multiple constructors would be complicated to say
the least, if not impossible. Named parameters are really no different than
the standard:

X x = new X();
x.Property = 10;

except that they have to be written in a more condensed form.

Consider you have two properties of type string, Name and Description

If you only want to set one of those, assuming the attribute doesn't require
both in the constructor, of course, you can. But if you use multiple
constructors there is no way to define a set of two constructors that will
allow you to set one and only one of the above properties.

Now, consider if you had 20 properties, the chances of being able to
generate all the possible combonations of properties in the constructor are
very very low, its likely you will run into the same problem somewhere. Not
to mention the hideous number of constructors.

[Ben R.]

Hi Daniel,

Thanks for the very thourough response. That was a very interesting example
with not being able to have 2 different constructors for the name and
description fields only. I did some experimenting and it looks like this
feature is only enabled for Attribute classes. Is this accurate? If so, why?
Also, is the key here that the field needs to have a property in order to be
settable in a named parameter or could one do the same with a public field?

Thanks...

-Ben

"Daniel O'Connell [C# MVP]" wrote:

"Ben R." <Be**@discussio ns.microsoft.co m> wrote in message
news:01******** *************** ***********@mic rosoft.com...

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?

It is flexibility more than anything else, I think. Considering the sets of
options an attribute has, multiple constructors would be complicated to say
the least, if not impossible. Named parameters are really no different than
the standard:

X x = new X();
x.Property = 10;

except that they have to be written in a more condensed form.

Consider you have two properties of type string, Name and Description

If you only want to set one of those, assuming the attribute doesn't require
both in the constructor, of course, you can. But if you use multiple
constructors there is no way to define a set of two constructors that will
allow you to set one and only one of the above properties.

Now, consider if you had 20 properties, the chances of being able to
generate all the possible combonations of properties in the constructor are
very very low, its likely you will run into the same problem somewhere. Not
to mention the hideous number of constructors.

[Daniel O'Connell [C# MVP]]

"cody" <de********@gmx .de> wrote in message
news:ut******** ******@TK2MSFTN GP14.phx.gbl...

There are already suggestions made to microsoft to include named
parameters
as a general language feature and not only as an exception allowed for
Attributes.
The trick is to find the most flexible and performant way to implement it.

No, the trick is convincing people its a bad idea without optional
parameters, which are a bad idea themselves, IMHO. Attributes do not have
named arguments, they simply have convienent property setters.

Flexiblity and performance are not the issue, the real trouble is
consistency, which you will not achieve. The language just isn't really
going to allow it

[Daniel O'Connell [C# MVP]]

"Ben R." <Be**@discussio ns.microsoft.co m> wrote in message
news:72******** *************** ***********@mic rosoft.com...

Hi Daniel,

Thanks for the very thourough response. That was a very interesting
example
with not being able to have 2 different constructors for the name and
description fields only. I did some experimenting and it looks like this
feature is only enabled for Attribute classes. Is this accurate? If so,
why?

[sorry, I thought I posted this earlier]

Yes, it is only available in attributes.

There are two reasons really, the first is that it allows for a very compact
syntax. No one would want to have to write out the equivilent non-attribute
code within an attribute block. The second reason is an enabling one,
because the syntax
Prop = Value
is not ambigous within an attribute whereas in normal method code it is
possible that you are trying to assign to a local property or variable and
not to a named attribute.

[cody]

Is the idea really this bad? For example the Graphics.DrawIm age method has
about 20 overloads with dozends of parameters. Did you ever have to usse
directX? Most methods have > 10 parameters and are heavyly overloaded. Then
you'd really wish you'd had named parameters.
I wouldn't enable named parameter passing per default: instead you would
have to explicitly mark the arguments as optional, which is, all
non-optional parameters will be positional parameters.

"Daniel O'Connell [C# MVP]" <[e-mail]> schrieb im
Newsbeitrag news:uw******** ******@TK2MSFTN GP14.phx.gbl...

"cody" <de********@gmx .de> wrote in message
news:ut******** ******@TK2MSFTN GP14.phx.gbl...

There are already suggestions made to microsoft to include named
parameters
as a general language feature and not only as an exception allowed for
Attributes.
The trick is to find the most flexible and performant way to implement it.

No, the trick is convincing people its a bad idea without optional
parameters, which are a bad idea themselves, IMHO. Attributes do not have
named arguments, they simply have convienent property setters.

Flexiblity and performance are not the issue, the real trouble is
consistency, which you will not achieve. The language just isn't really
going to allow it

[Daniel O'Connell [C# MVP]]

"cody" <de********@gmx .de> wrote in message
news:O%******** ********@tk2msf tngp13.phx.gbl. ..

Is the idea really this bad? For example the Graphics.DrawIm age method has
about 20 overloads with dozends of parameters. Did you ever have to usse
directX? Most methods have > 10 parameters and are heavyly overloaded.
Then
you'd really wish you'd had named parameters.

Yes, it is bad. There is nothing like adding a feature that makes what code
says and what code means differ(optional parameters, that is).

If you design a method that requires so many overloads and parameters that
named parameters is the only way to understandably use it, wouldn't you say
the method should be reconsidered? Graphics.DrawIm age is one of the most
obnoxious overloads ever created and adding features to make using it easier
is the wrong way to go, IMHO. Fix the interface, not the language.

DirectX is an interesting beast in that its interface was designed with
optional parameters in mind and with overloading disallowed. It has been
argued, well I might add, that the flaws in DirectX and many COM interfaces
are a direct result of the use of optional parameters over overloads. The
interfaces are monolithic and badly structured, making it rather difficult
to convert to .NET directly(manage d directX was pretyt poorly designed as
well). Again, its not the languages job to work around bad interfaces,
especially when the features could be the cause of the problem to begin
with.

Now, without any valid reason for optional parameters, named parameters have
little need.

And that still doesn't fix the issues with syntactical consistency. Optional
parameters give you a syntactic problem, namely that they do not work that
well with overloads as you cannot provide overloads that would clash with
optional arguments

consider:

public void Test(string x, optional string y);
public void Test(string x);

That would result in ambigious calling code, how do you get around that
without complicating the language even more?

Named parameters offer another problem, consider

Test("cat", y = "mouse")

and

string y;
Test("cat", y="mouse");

y="mouse" has two different meanings here, how do you get around that?

[Steve Walker]

In message <OA************ **@TK2MSFTNGP12 .phx.gbl>, "Daniel O'Connell
[C# MVP]" <[e-mail]> writes

"cody" <de********@gmx .de> wrote in message
news:O%******* *********@tk2ms ftngp13.phx.gbl ...

Is the idea really this bad? For example the Graphics.DrawIm age method has
about 20 overloads with dozends of parameters. Did you ever have to usse
directX? Most methods have > 10 parameters and are heavyly overloaded.
Then
you'd really wish you'd had named parameters.

Yes, it is bad. There is nothing like adding a feature that makes what code
says and what code means differ(optional parameters, that is).

If you design a method that requires so many overloads and parameters that
named parameters is the only way to understandably use it, wouldn't you say
the method should be reconsidered?

I'd agree. If I had a method which had a very large number of
parameters, many of which were optional, rather than having an overload
for each legal permutation I'd consider something along the lines of
passing a single parameter object.

--
Steve Walker

[cody]

>> Is the idea really this bad? For example the Graphics.DrawIm age method

has
about 20 overloads with dozends of parameters. Did you ever have to usse
directX? Most methods have > 10 parameters and are heavyly overloaded.
Then
you'd really wish you'd had named parameters.
Yes, it is bad. There is nothing like adding a feature that makes what
code says and what code means differ(optional parameters, that is).

If you design a method that requires so many overloads and parameters that
named parameters is the only way to understandably use it, wouldn't you
say the method should be reconsidered? Graphics.DrawIm age is one of the
most obnoxious overloads ever created and adding features to make using it
easier is the wrong way to go, IMHO. Fix the interface, not the language.

The questions is what is the alternative. Something like that?

ImageDraw d = new ImageDraw(g);
d.SrcRect = rect;
d.dstRect = rect;
d.DrawFlags = foo;
//..
d.Draw();

This would have the advantage that you can reuse this object so you do not
need to push all 20 arguments for every call on the stack,
so you can have a performance advantage.
DirectX is an interesting beast in that its interface was designed with
optional parameters in mind and with overloading disallowed. It has been
argued, well I might add, that the flaws in DirectX and many COM
interfaces are a direct result of the use of optional parameters over
overloads. The interfaces are monolithic and badly structured, making it
rather difficult to convert to .NET directly(manage d directX was pretyt
poorly designed as well).
I hope that Tom Miller will fix this in near future :)
public void Test(string x, optional string y);
public void Test(string x);

That would result in ambigious calling code, how do you get around that
without complicating the language even more?
You cannot overload a method which signature only differs in optional
arguments.
string y;
Test("cat", y="mouse");

y="mouse" has two different meanings here, how do you get around that?

You have to use a special operator/prefix to mark a named argument as such
for example

Test("cat", .y="mouse");
Test("cat", #y="mouse");
Test("cat", $y="mouse");

or similar.

[Daniel O'Connell [C# MVP]]

>> If you design a method that requires so many overloads and parameters

that named parameters is the only way to understandably use it, wouldn't
you say the method should be reconsidered? Graphics.DrawIm age is one of
the most obnoxious overloads ever created and adding features to make
using it easier is the wrong way to go, IMHO. Fix the interface, not the
language.
The questions is what is the alternative. Something like that?

ImageDraw d = new ImageDraw(g);
d.SrcRect = rect;
d.dstRect = rect;
d.DrawFlags = foo;
//..
d.Draw();

This would have the advantage that you can reuse this object so you do not
need to push all 20 arguments for every call on the stack,
so you can have a performance advantage.

That'd be one option, I certainly havn't taken the time to redesign the
graphics class, sorry to say, ;). DrawImage could be split into several
methods that more adequatly describe themselves instead of one that takes 20
different combinations of inputs(If I recall correctly, a big part of that
is allowing both floating point and integer sizes and positioning, correct?)

public void Test(string x, optional string y);
public void Test(string x);

That would result in ambigious calling code, how do you get around that
without complicating the language even more?

You cannot overload a method which signature only differs in optional
arguments.

Of course not, but that means optional potentially becomes the chief way to
overload, creating really crappy interfaces that assume optional is
supported and liked ala COM and VB. Once you throw optional into a method,
determining the safe overload set gets too complicated and you lose a great
many useful overload options anyway. So one optional parameter means
overloading is really unattractive, so is it actually worth it?

string y;
Test("cat", y="mouse");

y="mouse" has two different meanings here, how do you get around that?

You have to use a special operator/prefix to mark a named argument as such
for example

Test("cat", .y="mouse");
Test("cat", #y="mouse");
Test("cat", $y="mouse");

Which is ugly and inconsistent, IMHO, as it differs from how it works in
attributes(not to mention that the acutal *functionality* of the two setters
are very, very different). You would also end up with the oh-so-cute

[Attribute($y="m ouse",y="mouse" )]

as legal code that looks so similar but are actually entirely different in
meaning.

Do you really thing adding a keyword, functionality, and a variable prefix
to the language is the best way to solve any of these problems? Are named
parameters needed or is it just language envy?