Declaring without specifying default parameters
Notice the constructor includes default values. That means you can say things like:
This means the TextBoxInfo object will get:
Naming and omitting specific parameters is possible
The notice that optional parameters allow you to have several overloaded constructors.
Office Automation Needs this tremendously
Overload Resolution Algorithm
Adding support for default parameters in COM for MS Office massively complicates the overload resolution algoritm. The feature was painful to implement. What makes it difficult to support optional and named parameters in COM is the combination of many named parameters and the ability for the caller to change the order of parameters when calling into COM methods.
For named parameters, you go to verify that they are legitimate named parameters. Next, you may need to shuffle the order to match the actual method signature, in the event the caller altered the order or skipped parameters.
Inheritance complicates the picture
It can get extremely complex for the compiler writer. Note the example below.
Notice the second method in class "B" called "m()". The first method in the second method of overlap a lot in the class "B". Notice that both methods are so similar that the compiler simply does not know what to do. You can see that the calls to the "m()" method using the B object always resolves to the first method in the B class.
This blog focused on the complications of optional and a named parameters. Hopefully the concrete examples that I have provided will help you understand what is possible, as well as what might be ambiguous.
In the next log I will look at how this feature (optional and named parameters) can dramatically improve the ease with which to interact with Microsoft office and the component object model (COM).
PingBack from http://blog.a-foton.ru/index.php/2009/03/24/c-40-%e2%80%93-part-2-%e2%80%93-optional-and-named-parameters/
Thank you for submitting this cool story - Trackback from DotNetShoutout