why the delegate declaration needs named parameters?

  • Thread starter Thread starter Wiktor Zychla
  • Start date Start date
W

Wiktor Zychla

Hello,

I wonder why the delegate declaration needs named parameters?

public delegate void MyDelegate( int a, int b ); // ok
public delegate void MyDelegate( int, int ); // compiler error

C allows to define both:

typedef void (*MyDelegate)(int); // ok
typedef void (*MyDelegate)(int a); // ok

in fact, the delegates are only signatures, so the names should be
irrelevant. it could be even more elegant to use nameless signatures,
because now it looks rather confusing:

public delegate void MyDelegate( int a, int b ); // names: a, b
public void a_Method( int x, int y ) {} // names: x, y

.... MyDelegate m = new MyDelegate( a_Method ); // ok, but there's slight
confusion

while it could be:

public delegate void MyDelegate( int, int ); // a signature only
public void a_Method( int x, int y ) {} // names: x, y

.... MyDelegate m = new MyDelegate( a_Method );

thanks in advance for enlightening me,
Wiktor Zychla
 
Hi Wiktor,

I guess the part of the answer is for the methods BeginInvoke and EndInvoke
which are generated by (compiler) for each delegate - for naming parameters.
 
My guess:

They probably use the same grammer rule for the bit within
brackets for both delegate declarations and actual
function declarations. Probably done to reduce the size of
the language grammer, although it might be because some
IDEs automatically pick up function signatures, and seeing
something like func(int iIndex, int iOffset) popping up is
more useful than seeing func(int,int). .

C in contrast has a lot of historical quirks. To my
knowledge, this is valid Ansi C (a hangover from 1970's
K&R C):

int double(val) int val; { return val>>2; }
 
I guess the part of the answer is for the methods BeginInvoke and
EndInvoke
which are generated by (compiler) for each delegate - for naming
Click to expand...
parameters.

could not the compiler produce any irrelevant names itself?
I guess you never need the names in C#.
 
They probably use the same grammer rule for the bit within
brackets for both delegate declarations and actual
function declarations. Probably done to reduce the size of
the language grammer, although it might be because some
IDEs automatically pick up function signatures, and seeing
something like func(int iIndex, int iOffset) popping up is
more useful than seeing func(int,int). .
Click to expand...

that sounds reasonable but making the language spec to follow the IDE's
requirements is not advisable. what I think is that the C# could accept both
forms:

delegate int MyDelegate( int a, int b );
and
delegate int MyDelegate( int, int );
C in contrast has a lot of historical quirks. To my
Click to expand...

that's true. I just wanted to show that the nameless definition is clearer
and less confusing.
 
Hi Wiktor,


Wiktor Zychla said:
parameters.

could not the compiler produce any irrelevant names itself?
Click to expand...

But then they would be needless. I think it helps to have meaningful names
as parameters
Isn't better to have string firstName, string lastName then string, string
or string x, string y?
 
I can't answer why C# requires the names, but I can tell you that if it
didn't, I'd use them anyway.

There's a lot to be said for the kind of documentation that Intellisense
provides, and meaningful parameter names are great reminders of what goes
where.
 
Wiktor,

It must be something specific to the C# compiler given
that in managed C++ you are able to do the following:

__delegate int SomeCalculation(int);

Obviously by the time it has become MSIL it doesn't really
matter if there were names or not. What I haven't tried
that would be interesting is to use the above listed
delegate compiled into a C++ dll from C# and see what
names are chosen (if any) for the parameters.

JM
 
There is no language requirement that delegate parameters be named - we
could easily have spec'd C# so that they weren't required.

They are required because they improve readability considerably. When you go
to use a delegate, it's much easier to tell what's going on. Consider the
standard windows forms event handler:

public delegate void EventHandler(object, EventArgs);

that doesn't give you much information about the first parameter, while

public delegate void EventHandler(object sender, EventArgs e);

This is generally more of an issue when the type is one that could be used
in a lot of ways - such as object, int, etc.

Hope that helps.

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
 
Obviously by the time it has become MSIL it doesn't really
matter if there were names or not. What I haven't tried
that would be interesting is to use the above listed
delegate compiled into a C++ dll from C# and see what
Click to expand...

I've tested that.
the parameters are named "__unnamed000", "__unnamed001" and so on.
 
Back
Top