How to retrieve a method's name as a string?

[proxyuser]

I was hoping there was something like that built in, but maybe not. I'll
give that a try, thanks.

It is built in. Extensions are a new feature in .NET 3.5.

I was referring to the "ToString" imlemementation, not extensions.

 

[proxyuser]

I admit, it's not really clear to me what behavior you're really trying to
accomplish here. Assuming that "option 1" would actually satisfy the
requirement, how is having to hard-code the method name in a call to
Type.GetMethod() any different than simply hard-coding the method name in
some output method? Why is "option 1" even an option at all?

Because in that case, it would at least fail at run time when the call was
made. Then someone would know something is wrong and be forced to change
it. If they simply hard coded the output string, nothing would ever fail.
The output would be wrong though.

That is, I understand that being able to do so would ensure refactoring
the code results in the string effectively being refactored as well, but
what is the real goal here? What ultimate benefit do you achieve by being
able to convert the name of a method you're about to call into a string?
And why can that benefit not be achieved by moving the logic emitting
and/or using that string into the method being called, rather than at each
call site?

What are you really trying to do here?

Think of this example. I'm not giving a reason why you'd want to write this
code, I'm just saying if you did, the second example is better. The reason
is that if the control name ever changes, the code will still work. I want
to do this, but with method names.

TextBox b1 = new TextBox();
b1.Name = "b1";
TextBox b2 = new TextBox();
b2.Name = "b2";

// bad
void f(Control c)
{
if (c.Name.Equals("b1"))
{
// output trace message that "function f is operating on control b1"
}
}

// better
void f(Control c)
{
if (c.Name.Equals(b1.Name))
{
// output trace message that String.Format("function f is operating on
control {0}", b1.Name)
}
}

 

[proxyuser]

I admit, it's not really clear to me what behavior you're really trying to
accomplish here. Assuming that "option 1" would actually satisfy the
requirement, how is having to hard-code the method name in a call to
Type.GetMethod() any different than simply hard-coding the method name in
some output method? Why is "option 1" even an option at all?

Because in that case, it would at least fail at run time when the call was
made. Then someone would know something is wrong and be forced to change
it. If they simply hard coded the output string, nothing would ever fail.
The output would be wrong though.

That is, I understand that being able to do so would ensure refactoring
the code results in the string effectively being refactored as well, but
what is the real goal here? What ultimate benefit do you achieve by being
able to convert the name of a method you're about to call into a string?
And why can that benefit not be achieved by moving the logic emitting
and/or using that string into the method being called, rather than at each
call site?

What are you really trying to do here?

Think of this example. I'm not giving a reason why you'd want to write this
code, I'm just saying if you did, the second example is better. The reason
is that if the control name ever changes, the code will still work. I want
to do this, but with method names.

TextBox b1 = new TextBox();
b1.Name = "b1";
TextBox b2 = new TextBox();
b2.Name = "b2";

// bad
void f(Control c)
{
if (c.Name.Equals("b1"))
{
// output trace message that "function f is operating on control b1"
}
}

// better
void f(Control c)
{
if (c.Name.Equals(b1.Name))
{
// output trace message that String.Format("function f is operating on
control {0}", b1.Name)
}
}

 

[proxyuser]

This is not going to work because to get the name of the method you
must first know the name of the method.

That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.

I have to ask is this information is of any real value to the user?

You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.

 

[proxyuser]

This is not going to work because to get the name of the method you
must first know the name of the method.

That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.

I have to ask is this information is of any real value to the user?

You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.

 

[proxyuser]

This is not going to work because to get the name of the method you
must first know the name of the method.

The point is, I do know the name of the method, but I want to specify the
name in a form known to the compiler so changes can automatically be
handled. If I specify it in the form of a quoted string, the compiler can't
deal with it.

 

[proxyuser]

This is not going to work because to get the name of the method you
must first know the name of the method.

The point is, I do know the name of the method, but I want to specify the
name in a form known to the compiler so changes can automatically be
handled. If I specify it in the form of a quoted string, the compiler can't
deal with it.

 

[proxyuser]

All due respect, but it would be unwise for any of us to take anything for
granted. The mere fact that you _want_ to do something does not in and of
itself prove that it's of value.

Well, it's proof that I want to do it, but frankly I'm a veteran of multiple
fora, and while I appreciate the volunteer nature of the answers, I do lose
patience with people who want to convince me I don't want to do something or
I shouldn't be asking the question. If they don't want to answer, they
don't have to, but please don't tell me I shouldn't be asking the question.
If someone can't conceive of any reason I might want to do something, then
they can simply consider it a theoretical exercise. If they don't want to
participate in a theoretical exercise, then don't.

Isn't incorrect output at run-time a failure? If someone's looking at the
output and sees the name of a method that doesn't exist, that seems like
that would be an indication that something's wrong.

Even if you don't accept my scenario, I'm sure you could come up with one
where this is valid. A tester is tasked with testing an API, and turns on
an application flag that gives trace output to the user. They click on a
menu option to determine what function is called when that event occurs.
They determine that the wrong function is being called and a bug is opened.
It turns out that the correct function is actually being called, but the
trace output was wrong. The trace output was wrong because the API changed
and the developer changed the function call, but did not change the trace
output. A bug is submitted, requiring a fix and a new build. Or there is
simply some back and forth to determine if there is actually any problem,
wasting time in the process. A compile error would have short circuited
this process from the start.

I'm sure you can think of other scenarios.

The above breaks if someone fails to set the Name property correctly

The name property is set by Windows designer, not the developer. But that
point is moot, because the point is *how* the error is caught, not *if*
something breaks. A compile error is preferrable to manual detection by a
person.

People waste time on things that turn out to be useless, or at the very
least the wrong approach, all the time. I see no reason to believe that
you are somehow magically immune to that particular aspect of the human
condition.

People also waste time on forums telling other people what they should be
spending their time on (I'm not referring to you.)

As I said before, until you can precisely describe what your actual
ultimate goal is, it's impossible to offer any really good advice.

My ultimate goal is to get the name of a function programmatically. You say
it can't be done, so that's that.

 

[proxyuser]

All due respect, but it would be unwise for any of us to take anything for
granted. The mere fact that you _want_ to do something does not in and of
itself prove that it's of value.

Well, it's proof that I want to do it, but frankly I'm a veteran of multiple
fora, and while I appreciate the volunteer nature of the answers, I do lose
patience with people who want to convince me I don't want to do something or
I shouldn't be asking the question. If they don't want to answer, they
don't have to, but please don't tell me I shouldn't be asking the question.
If someone can't conceive of any reason I might want to do something, then
they can simply consider it a theoretical exercise. If they don't want to
participate in a theoretical exercise, then don't.

Isn't incorrect output at run-time a failure? If someone's looking at the
output and sees the name of a method that doesn't exist, that seems like
that would be an indication that something's wrong.

Even if you don't accept my scenario, I'm sure you could come up with one
where this is valid. A tester is tasked with testing an API, and turns on
an application flag that gives trace output to the user. They click on a
menu option to determine what function is called when that event occurs.
They determine that the wrong function is being called and a bug is opened.
It turns out that the correct function is actually being called, but the
trace output was wrong. The trace output was wrong because the API changed
and the developer changed the function call, but did not change the trace
output. A bug is submitted, requiring a fix and a new build. Or there is
simply some back and forth to determine if there is actually any problem,
wasting time in the process. A compile error would have short circuited
this process from the start.

I'm sure you can think of other scenarios.

The above breaks if someone fails to set the Name property correctly

The name property is set by Windows designer, not the developer. But that
point is moot, because the point is *how* the error is caught, not *if*
something breaks. A compile error is preferrable to manual detection by a
person.

People waste time on things that turn out to be useless, or at the very
least the wrong approach, all the time. I see no reason to believe that
you are somehow magically immune to that particular aspect of the human
condition.

People also waste time on forums telling other people what they should be
spending their time on (I'm not referring to you.)

As I said before, until you can precisely describe what your actual
ultimate goal is, it's impossible to offer any really good advice.

My ultimate goal is to get the name of a function programmatically. You say
it can't be done, so that's that.

 

[Registered User]

That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.

A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread. Even an ASP.NET
control's ControlId property isn't relevant although that value is
automagically populated. The original question was about identifying
object methods by name without knowing their names. Different objects
of the same type all have the same method names regardless of the
objects' Name or, if supported, ControlId property.

You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.

Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah

regards
A.G.

 

[Registered User]

That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.

A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread. Even an ASP.NET
control's ControlId property isn't relevant although that value is
automagically populated. The original question was about identifying
object methods by name without knowing their names. Different objects
of the same type all have the same method names regardless of the
objects' Name or, if supported, ControlId property.

You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.

Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah

regards
A.G.

 

[proxyuser]

A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread.

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

 

[proxyuser]

A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread.

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

 

[Registered User]

But we're not discussing all objects. The comment was specific to
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

I fail to see how an object's Name property can be used to identify
the name of a specific method of the type. A method is not an object
and does not have a Name property.

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

Being able to understand the why plays a big part in determining
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.

Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.

Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.

regards
A.G.

 

[Registered User]

But we're not discussing all objects. The comment was specific to
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

I fail to see how an object's Name property can be used to identify
the name of a specific method of the type. A method is not an object
and does not have a Name property.

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

Being able to understand the why plays a big part in determining
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.

Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.

Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.

regards
A.G.

 

[J.B. Moreno]

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

The name property can be changed at run time -- it can even be changed
outside of the designer before compiling. Never rely upon the name
property being the same as the variable name.

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

Such responses indicate one of three things:
1) You have either failed to adequately explain what the real
problem you are trying to solve is (and not just the method you've
chosen to solve the problem).
2) You don't need to do that.
3) Your reader is unable to understand how to apply what you want to
do to solve your problem (this is just a variation on 1 but putting the
onus on the reader).


Now, on to your actual question. I haven't done it in practice, but I
believe that theoretically this is at least a *partly solvable problem.

1. Do not call the method directly, instead create a delegate and
call it using the delegate.
2. Use instance.GetType.GetMethods() to create a collection of
MethodInfo's
3. Use Delegate.CreateDelegate to create a delegate for each of the
methodsinfo's created inst step 2.
4. Use Delegate.Equals to compare the delegate created in step 1, to
the ones created in step 3. Then use the associated MethodInfo.Name.

5. Bob's your uncle.

*I said partly solvable because I for see problems with methods that
have more than one parameter.

 

[J.B. Moreno]

See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.

The name property can be changed at run time -- it can even be changed
outside of the designer before compiling. Never rely upon the name
property being the same as the variable name.

Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.

Such responses indicate one of three things:
1) You have either failed to adequately explain what the real
problem you are trying to solve is (and not just the method you've
chosen to solve the problem).
2) You don't need to do that.
3) Your reader is unable to understand how to apply what you want to
do to solve your problem (this is just a variation on 1 but putting the
onus on the reader).


Now, on to your actual question. I haven't done it in practice, but I
believe that theoretically this is at least a *partly solvable problem.

1. Do not call the method directly, instead create a delegate and
call it using the delegate.
2. Use instance.GetType.GetMethods() to create a collection of
MethodInfo's
3. Use Delegate.CreateDelegate to create a delegate for each of the
methodsinfo's created inst step 2.
4. Use Delegate.Equals to compare the delegate created in step 1, to
the ones created in step 3. Then use the associated MethodInfo.Name.

5. Bob's your uncle.

*I said partly solvable because I for see problems with methods that
have more than one parameter.

 

[proxyuser]

Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.

Why does it need to have any value? Just look at it as a theoretical
question so I can understand the language better. If you prefer not to
answer any questions for which you don't see any value, then just exercise
that prerogative.

 

[proxyuser]

Such responses indicate one of three things:
1) You have either failed to adequately explain what the real
problem you are trying to solve is (and not just the method you've
chosen to solve the problem).
2) You don't need to do that.
3) Your reader is unable to understand how to apply what you want to
do to solve your problem (this is just a variation on 1 but putting the
onus on the reader).

I really don't see why it matters. Just assume the real problem I'm trying
to solve is getting a method name from a method programmatically and go from
there. I know people are trying to help when they ask "why do you need
that", but as you can imagine it can get rather tedious over the years on
forums where you have to waste time arguing about something that just gets
in the way. You and I both know there are people who would rather spend
energy telling someone what they should or shouldn't do rather than spending
the energy on an answer, or even just not cluttering up the thread to begin
with.

Now, on to your actual question. I haven't done it in practice, but I
believe that theoretically this is at least a *partly solvable problem.

1. Do not call the method directly, instead create a delegate and
call it using the delegate.
2. Use instance.GetType.GetMethods() to create a collection of
MethodInfo's
3. Use Delegate.CreateDelegate to create a delegate for each of the
methodsinfo's created inst step 2.
4. Use Delegate.Equals to compare the delegate created in step 1, to
the ones created in step 3. Then use the associated MethodInfo.Name.

5. Bob's your uncle.

*I said partly solvable because I for see problems with methods that
have more than one parameter.

Off the top of my head I don't see what the problems would be with more than
one parameter - it seems like that would work. That's an idea that
definitely did not occur to me - see, that's why these newsgroups are so
good

 

[J.B. Moreno]

-snip need to explain real problem-

I really don't see why it matters. Just assume the real problem I'm trying
to solve is getting a method name from a method programmatically and go from
there. I know people are trying to help when they ask "why do you need
that", but as you can imagine it can get rather tedious over the years on
forums where you have to waste time arguing about something that just gets
in the way. You and I both know there are people who would rather spend
energy telling someone what they should or shouldn't do rather than spending
the energy on an answer, or even just not cluttering up the thread to begin
with.

It matters for several reasons, possibly the least important is
motivation for people to put effort into solving your problem even if
they don't know the answer right off hand.

Another point. By definition, since you're asking the question, the
people that can best answer it know more about that particular area of
programming than you do, if they think that they need additional
information...

As for getting tired of it, just include it as a matter of course if
the question seems weird. Which this one certainly is, as the normal
method would be to do whatever you ned to do inside the method itself.

Off the top of my head I don't see what the problems would be with more than
one parameter - it seems like that would work. That's an idea that
definitely did not occur to me - see, that's why these newsgroups are so
good

The problem with more than one parameter is that the delegates are
unlikely to evaluate to equal with a different parameter list.

OTOH, I'm not sure what the output of Delegate.ToString is, and on
second thought that seems much more straightforward and reliable if it
does the obvious (output the method name/signature).