why the delegate declaration needs named parameters?

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
 
M

Miha Markic

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

R Horton

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; }
 
W

Wiktor Zychla

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.

could not the compiler produce any irrelevant names itself?
I guess you never need the names in C#.
 
W

Wiktor Zychla

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

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

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

Miha Markic

Hi Wiktor,


Wiktor Zychla said:
parameters.

could not the compiler produce any irrelevant names itself?

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?
 
J

Jerry Houston

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

Jason M

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
 
E

Eric Gunnerson [MS]

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

Wiktor Zychla

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

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top