[Mono-dev] Parameter names and class status

[Robert Jordan]

Leszek Ciesielski wrote:
> On 10/20/06, Leszek Ciesielski <skolima at gmail.com> wrote:
>> On 10/20/06, Robert Jordan <robertj at gmx.net> wrote:
>>> Leszek Ciesielski wrote:
>>>> Hi,
>>>>
>>>> I took a quick glance at corcompare utility, and it seems to ignore
>>>> parameter names. And those are also part of API contract (eg. Spring
>>>> uses them in configuration files). So I made a quick update to the
>>>> GetSignature method. Please review.
>>> Would you please post a link to the docs stating that parameter names
>>> are part of the API contract?
>>
>> Hmm. It seemed obvious to me, although you are right to ask. I found this:
>> http://www.gotdotnet.com/team/changeinfo/default.aspx (look under
>> Binary Breaking Changes), but this is not a Microsoft/ECMA document.
>> I'll look for something official.
> 
> OK. From ECMA CLI specification (Ecma-355), the DTD for assembly
> information (7.1):
> element Parameters is a required element of Member
> element Parameters is a list of Parameter elements
> element Parameter is:
> 
> <!ELEMENT Parameter (Attributes?)>
>   <!ATTLIST Parameter
>         Name NMTOKEN #REQUIRED
>         Type CDATA #REQUIRED

The DTD is meaningless for this problem. It just describes
the format of the XML API. It says that a parameter name
is required. Not more and not less.

> MSDN guidelines for parameter design (
> http://msdn2.microsoft.com/en-us/library/ms229015.aspx ):
> 
> "Do be consistent in naming parameters when overriding members or
> implementing interface members.
> Overrides should use the same parameter names. Overloads should use
> the same parameter names as the declaring member. Interface
> implementations should use the same names defined in the interface
> member signature."

Everywhere "should". This doesn't sound mandatory to me.

> While the second excerpt is only a guideline, the first one is part of
> the ECMA standard. And even if it was not, some existing programs (as
> the aforementioned Spring.Net framework) rely on parameter names when
> binding methods through reflection.

I don't agree. The first is just a plain XML constraint.

Though I really want to use passing by name, I'm not convinced
it's a good idea.

How many differences did you patch uncover?

Robert