Optional and named parameters in an Attribute..?

[JuggaloBrotha]

I thought named attributes were added to .Net 2.0 for better COM compatibility. Though I didn't see people using them until VS2008 and even then the only ones I'd ever seen used were one those 'Declare Function' calls to an external COM object or an API call to shell.dll

Outside of that the only other time I've ever seen them used are in vb6/vba apps, which is basically COM based anyways.

I guess I've just never really seen a practical use for them in .Net yet.

[NickThissen]

Attributes don't really work in a standard manner here. I want to say they actually predate Optional arguments in VB .NET, but I can't remember if that's right or not. At the very least, I know how it does work.

Peek at AttributeUsage's constructor. See any optional arguments? Nope. So how does it get to use optional arguments?

Attributes are treated specially, that's how. The .NET CLR doesn't actually require that a language support optional parameters, and for a long time C# didn't support them. But it was definitely a boon to have optional parameters for attribute declarations, so a weirdo compiler trick was used instead.

For attribute classes (and only classes used as attributes), here is the convention. Positional "unnamed" parameters are specified as arguments to the constructor of the class. They are expected to have the same name as read-only properties of the class, but allowed to differ by case. Named parameters are not listed in the constructor, but instead listed as read/write properties of the class. When you specify a named parameter, the compiler uses reflection to verify that the parameter name corresponds to a read/write property and generates code to set the value of that property after constructing the attribute object. In this way, languages that don't support optional/named parameters (like C# up to 4.0 but technically no .NET language was *required* to implement them) can still use something like them for attributes.

Thus, when you design an attribute, you have to follow these rules:

• You should only have properties that you intend to correspond to parameters that are set when the attribute is applied.
• Any properties you intend to be required should be read-only and have a corresponding constructor parameter that sets them.
• Any properties you intend to be optional or named should be read/write and not be part of the constructor.

It's a bit messed up, but it's the best they could do in .NET 1.0.

*edit*
Found an MSDN entry that explains it in a sort of roundabout way.

Thanks. I knew C# didn't support named or optional parameters before .NET 4.0, but I've always thought they were part of VB.NET and hence could be used in Attributes (as long as you were working in VB) as usual. Apparently not. It's getting late so I haven't read all of it yet, I'll do that tomorrow.

I thought named attributes were added to .Net 2.0 for better COM compatibility. Though I didn't see people using them until VS2008 and even then the only ones I'd ever seen used were one those 'Declare Function' calls to an external COM object or an API call to shell.dll

Outside of that the only other time I've ever seen them used are in vb6/vba apps, which is basically COM based anyways.

I guess I've just never really seen a practical use for them in .Net yet.

Do you mean named parameters? Or specifically named parameters in attributes? Named parameters are quite common aren't they? I can see great practical use for them, as long as you have a method with a lot of optional parameters. If you have a method with, say, 10 optional parameters and you only want to specify the last one, then without named parameters you could either:
1. Supply the default value for each parameter (so you have to look them up), or
2. Leave it empty, resulting in a method call like

Me.SomeMethod(,,,,,,,,,"Finally..")

Yeah... not really the syntactic sugar VB promised to have

With named parameters you just do

Me.SomeMethod(lastValue:="Finally..")

Much easier to read.


And even with normal methods I can see some use for them. If you are calling some method that you don't really know, I find it useful to supply the parameter names just so I can see what the various values do. For example, this:

Me.CountElements(CountStrings:=True, CountIntegers:=True, CountDates:=False, CountDoubles:=False)

is much easier to read at a glance then

Me.CountElements(True, True, False, False)

unless you know exactly in which order the parameters are declared.