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]]

Re: Named parameters?


"Ben R." <BenR@discussio ns.microsoft.co m> wrote in message
news:01F6D0AC-4A3F-4BF4-8162-651B8763A73F@mi crosoft.com...[color=blue]
> 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?
>[/color]

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.]

Re: Named parameters?

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:
[color=blue]
>
> "Ben R." <BenR@discussio ns.microsoft.co m> wrote in message
> news:01F6D0AC-4A3F-4BF4-8162-651B8763A73F@mi crosoft.com...[color=green]
> > 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?
> >[/color]
>
> 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.
>
>
>[/color]

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"cody" <deutronium@gmx .de> wrote in message
news:utVXuXUVFH A.2256@TK2MSFTN GP14.phx.gbl...[color=blue]
> 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.
>[/color]

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]]

Re: Named parameters?


"Ben R." <BenR@discussio ns.microsoft.co m> wrote in message
news:7276FDF7-DC8D-4E4B-8462-819156FA306E@mi crosoft.com...[color=blue]
> 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?[/color]

[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]

Re: Named parameters?

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]" <onyxkirx@--NOSPAM--comcast.net> schrieb im
Newsbeitrag news:uwi3jZZVFH A.2128@TK2MSFTN GP14.phx.gbl...[color=blue]
>
> "cody" <deutronium@gmx .de> wrote in message
> news:utVXuXUVFH A.2256@TK2MSFTN GP14.phx.gbl...[color=green]
> > 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[/color][/color]
it.[color=blue][color=green]
> >[/color]
>
> 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
>
>
>[/color]

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"cody" <deutronium@gmx .de> wrote in message
news:O%23eMjdfV FHA.1148@tk2msf tngp13.phx.gbl. ..[color=blue]
> 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.[/color]

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]

Re: Named parameters?

In message <OAg4QwnVFHA.30 76@TK2MSFTNGP12 .phx.gbl>, "Daniel O'Connell
[C# MVP]" <onyxkirx@--NOSPAM--comcast.net> writes[color=blue]
>
>"cody" <deutronium@gmx .de> wrote in message
>news:O%23eMjdf VFHA.1148@tk2ms ftngp13.phx.gbl ...[color=green]
>> 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.[/color]
>
>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?[/color]

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]

Re: Named parameters?

>> Is the idea really this bad? For example the Graphics.DrawIm age method[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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.
[color=blue]
> 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).[/color]

I hope that Tom Miller will fix this in near future :)
[color=blue]
> 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?[/color]

You cannot overload a method which signature only differs in optional
arguments.
[color=blue]
> string y;
> Test("cat", y="mouse");
>
> y="mouse" has two different meanings here, how do you get around that?[/color]

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]]

Re: Named parameters?

>> If you design a method that requires so many overloads and parameters[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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?)
[color=blue]
>[color=green]
>> 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?[/color]
>
> You cannot overload a method which signature only differs in optional
> arguments.
>[/color]

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?
[color=blue][color=green]
>> string y;
>> Test("cat", y="mouse");
>>
>> y="mouse" has two different meanings here, how do you get around that?[/color]
>
> 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");
>[/color]

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?

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"Steve Walker" <steve@otolith. demon.co.uk> wrote in message
news:hNxMFLCYNp gCFwHw@otolith. demon.co.uk...[color=blue]
> In message <OAg4QwnVFHA.30 76@TK2MSFTNGP12 .phx.gbl>, "Daniel O'Connell [C#
> MVP]" <onyxkirx@--NOSPAM--comcast.net> writes[color=green]
>>
>>"cody" <deutronium@gmx .de> wrote in message
>>news:O%23eMjd fVFHA.1148@tk2m sftngp13.phx.gb l...[color=darkred]
>>> 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.[/color]
>>
>>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?[/color]
>
> 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.
>[/color]

That or consider why the method has so many overloads and either extract it
into another object, split the methods up into several methods that each do
atomic operations, or draw lines on functionality(i e a knife should be a
knife, not a fork, spoon, and mini-tv). It all depends on the exact
interface.

A parameter object or extracting the method into one or more independent
classes seems to be the best option in this case.

Now, what might be interesting would be considering syntax to simplify
parameter object creation. It probably wouldn't be a *good* idea in the
language but it is an interesting thought project. Maybe something like:

public void MyMethod(parame ter MyParameterObje ct paramObject = new
MyParameterObje ct);

MyMethod(parame ter.Name = "cheese", parameter.Age = 15);
or

MyMethod(parame ter MyParameterObje ct
{
Name = "cheese";
Age = 15;
});

or even a more generalized new ctor { propertySetters } syntax

new MyParameterObje ct()
{
Name = "cheese";
Age = 15;
};

It adds support for a (IMHO) better design pattern than optional parameters,
thoughts anyone?

[Ben R.]

RE: Named parameters?

Thanks once again, Dan. This was an interesting discussion to follow.

-Ben

"Ben R." wrote:
[color=blue]
> 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[/color]

[cody]

Re: Named parameters?

> Now, what might be interesting would be considering syntax to simplify[color=blue]
> parameter object creation. It probably wouldn't be a *good* idea in the
> language but it is an interesting thought project. Maybe something like:
>
> public void MyMethod(parame ter MyParameterObje ct paramObject = new
> MyParameterObje ct);
>
> MyMethod(parame ter.Name = "cheese", parameter.Age = 15);
> or
>
> MyMethod(parame ter MyParameterObje ct
> {
> Name = "cheese";
> Age = 15;
> });
>
> or even a more generalized new ctor { propertySetters } syntax
>
> new MyParameterObje ct()
> {
> Name = "cheese";
> Age = 15;
> };
>
> It adds support for a (IMHO) better design pattern than optional
> parameters, thoughts anyone?[/color]


Anders Hejlsberg spoke in a panel about a new syntax proposal for creating
objects (not just for parameter passing). It was something like that:

int age = 15;
MyClass mc = new MyClass{ Name="Herbert", Age = age; }

In that case you do not have the problem of syntax ambiguity because only
property assignments are allowed, on the left side a property of that object
is expected, and on the right side you cannot access members of that object.

But then you cannot do something like that:

Point p = new Point{X=10, Y=X}

because you cannot access X from there. In that case you have to use my
proposed character which distinguishes between a property of that object and
a local variable.

[Daniel O'Connell [C# MVP]]

Re: Named parameters?


"cody" <deutronium@gmx .de> wrote in message
news:ORGKh6UWFH A.1508@tk2msftn gp13.phx.gbl...[color=blue][color=green]
>> Now, what might be interesting would be considering syntax to simplify
>> parameter object creation. It probably wouldn't be a *good* idea in the
>> language but it is an interesting thought project. Maybe something like:
>>
>> public void MyMethod(parame ter MyParameterObje ct paramObject = new
>> MyParameterObje ct);
>>
>> MyMethod(parame ter.Name = "cheese", parameter.Age = 15);
>> or
>>
>> MyMethod(parame ter MyParameterObje ct
>> {
>> Name = "cheese";
>> Age = 15;
>> });
>>
>> or even a more generalized new ctor { propertySetters } syntax
>>
>> new MyParameterObje ct()
>> {
>> Name = "cheese";
>> Age = 15;
>> };
>>
>> It adds support for a (IMHO) better design pattern than optional
>> parameters, thoughts anyone?[/color]
>
>
> Anders Hejlsberg spoke in a panel about a new syntax proposal for creating
> objects (not just for parameter passing). It was something like that:[/color]

What panel was that?[color=blue]
> But then you cannot do something like that:
>
> Point p = new Point{X=10, Y=X}
>
> because you cannot access X from there. In that case you have to use my
> proposed character which distinguishes between a property of that object
> and a local variable.
>[/color]

Which is a wholely bad idea, IMHO. You wouldn't do new Point(10, X) either.
I don't really see how this relates to named parameters either. I really
think adding a character to distinguish between properties and variables is
one step into turning the langauge into a mess not worth working with. I am
concerned with the future of the language as it is, I've seen few
suggestions that are really as nice as some want. COmega is ugly as hell,
polyphonic C# is passable but close to dangerous, and some of Anders
suggestions on whiteboards havn't been really attractive.

[cody]

Re: Named parameters?

>>> It adds support for a (IMHO) better design pattern than optional[color=blue][color=green][color=darkred]
>>> parameters, thoughts anyone?[/color]
>>
>>
>> Anders Hejlsberg spoke in a panel about a new syntax proposal for
>> creating objects (not just for parameter passing). It was something like
>> that:[/color]
>
> What panel was that?[/color]

I found it on msdn TV, just look into the archives of microsoft.com after
"csharp features - AndersHejlsberg _300.wmv".
[color=blue][color=green]
>> But then you cannot do something like that:
>>
>> Point p = new Point{X=10, Y=X}
>>
>> because you cannot access X from there. In that case you have to use my
>> proposed character which distinguishes between a property of that object
>> and a local variable.
>>[/color]
>
> Which is a wholely bad idea, IMHO. You wouldn't do new Point(10, X)
> either. I don't really see how this relates to named parameters either.[/color]

It would make it easier/less verbose to create parameter objects.
[color=blue]
> I really think adding a character to distinguish between properties and
> variables is one step into turning the langauge into a mess not worth
> working with.[/color]

Maybe you're right. A character for distinguishing was just a suggestion,
maybe not a good one.