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

  • Thread starter Thread starter proxyuser
  • Start date Start date
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.
Click to expand...
My initial post was to point out why your proposed reflection solution
wouldn't work, the name of the method is needed to get the MethodInfo
object and the MethodInfo object is needed to get the name of the
method. More specific details were requested but none were provided
save an irrelevant something about the Name property of a Windows
control.

Theoretical questions do not always provide concrete answers from
which sound implementations can result. In your case the theoretical
question is flawed because it does not consider methods of different
types that share the same name, methods of type that share the same
name (overloading) and methods which have no names (anonymous
delegates). Please note this flaw is not value-based.

I apologize for not providing the answer you want to hear. The
responses your question has received all have a commonality except for
the one provided by sqlguru. His answer is just like your
reflection-based solution, the name of the method is required to get
the name of the method.

regards
A.G.
 
Registered User said:
I apologize for not providing the answer you want to hear. The
responses your question has received all have a commonality except for
the one provided by sqlguru. His answer is just like your
reflection-based solution, the name of the method is required to get
the name of the method.
Click to expand...

Except that it's not. I provided two possible solutions (and will now
provide a third).

All of them rely upon using delegates, but apparently that's not a
problem.


(Code by hand, if it doesn't compile, tough, the basic idea is sound).


public class Example {


public delegate String myMethodDelegate( int myInt );

// Defines an instance method.
public String myStringMethod ( int myInt ) {
if ( myInt > 0 )
return( "Hello" );
if ( myInt < 0 )
return( "Goodbye" );
return ( "Say, what?" );
}

public static void Main() {

myMethodDelegate myD1 = new myMethodDelegate( myStringMethod );

Console.WriteLine(myDl.Method.Name() + ", " + myDl(1));
}
 
Registered User said:
My initial post was to point out why your proposed reflection solution
wouldn't work, the name of the method is needed to get the MethodInfo
object and the MethodInfo object is needed to get the name of the
method. More specific details were requested but none were provided
save an irrelevant something about the Name property of a Windows
control.
Click to expand...

An "irrelevant something"? Sheesh, remind me not to bother explaining these
ideas anymore. And you wonder why I get annoyed at having to drag out these
conversations longer than they need be.... Moreno provided another good
example of a property on a delegate that provides the name of the thing you
want.
 
Except that it's not. I provided two possible solutions (and will now
provide a third).
Click to expand...
I was referring to the suggested use of
object.GetType().GetMethod(...)
which both the OP and sqlguru considered as possible solutions.
Apparently I hadn't read your post at the time.
All of them rely upon using delegates, but apparently that's not a
problem.


(Code by hand, if it doesn't compile, tough, the basic idea is sound).


public class Example {


public delegate String myMethodDelegate( int myInt );

// Defines an instance method.
public String myStringMethod ( int myInt ) {
if ( myInt > 0 )
return( "Hello" );
if ( myInt < 0 )
return( "Goodbye" );
return ( "Say, what?" );
}

public static void Main() {

myMethodDelegate myD1 = new myMethodDelegate( myStringMethod );

Console.WriteLine(myDl.Method.Name() + ", " + myDl(1));
}
Click to expand...
This is good solution because the indirection doesn't require the
method's name to be hardwired in the code as a string. Incomplete
changes will be caught by the compiler.

My why question involves what the user needs the name of the method
for. If the purpose is to identify the specific method using the name
alone will not always be suitable. Overload the myStringMethod to take
a float instead of an int and the name "myStringMethod" becomes
ambiguous. I have no idea if this ambiguity is suitable or if method
signatures are need to distinguish between methods of the same name.
The same name-only ambiguity could be an issue with derived types and
methods declared in their base class.

These are things I would point out if a client came to me with the
same loosely defined requirements. "Let us debug the requirements
before proceeding to any design or coding considerations."

Depending upon the unknowns the solutions you have provided may or may
not be suitable for the OP's requirements. At the very least you have
illustrated the complications required. Granted the use of delegates
isn't really a complication, the cumulative effort required to create
and use delegates for every method in an application could easily
become a major complication. I don't want to think about maintenance,
all the additional indirection might come across as unnecessary
obfuscation.

The OP has solutions that meet the expressed requirements. Of course
if the user needs to see the name of the delegate.... In any case it
is now up to the OP to make a value-based decision about if the
additional effort and code is justified by the need.

regard
A.G.
 
Registered User said:
I was referring to the suggested use of
object.GetType().GetMethod(...)
which both the OP and sqlguru considered as possible solutions.
Apparently I hadn't read your post at the time.
Click to expand...

I was referring to all of the answers sharing a commonality, which
required you to apologize.
-snip-
This is good solution because the indirection doesn't require the
method's name to be hardwired in the code as a string. Incomplete
changes will be caught by the compiler.
Click to expand...

None of the 3 solutions using delegates require hardwiring a string.
My why question involves what the user needs the name of the method
for.
Click to expand...

And that's a reasonable question, but it's no reason to put down the
OP's question. I have found the OP's refusal to answer that question
irritating, but so is the insistence upon an answer.

The OP's problem is obviously development related, something to do with
code coverage or usage, while it's possible a complete answer to "why"
would offer an alternate solution, it's just as possible that he's
right and this is the solution he needs.
 
I was referring to all of the answers sharing a commonality, which
required you to apologize.
Click to expand...
The commonality I was referring to involves the questions about what
is trying to be accomplished and why it is necessary.
None of the 3 solutions using delegates require hardwiring a string.
Click to expand...
Yes this is true. My comment was directed at the specific code snippet
provided in the post I was responding to.
And that's a reasonable question, but it's no reason to put down the
OP's question. I have found the OP's refusal to answer that question
irritating, but so is the insistence upon an answer.
Click to expand...
I wasn't putting down the OP's question as much as the OP's reluctance
to provide further details.This includes why the method name has to
been displayed to the user before the method is invoked rather than
from within the method itself.
The OP's problem is obviously development related, something to do with
code coverage or usage, while it's possible a complete answer to "why"
would offer an alternate solution, it's just as possible that he's
right and this is the solution he needs.
Click to expand...

Or possibly design-related since the OP did mention something about
method names being changed as one reason to avoid hardwiring strings.
Either way I can't fathom the why of displaying method names to the
user. If it is of value in the OP's project I'd like to know the
details because I might find it useful in situations I haven't
experienced yet.

You are correct about alternate solutions and with the limited
information provided not doing it seems like a valid alternative. The
crux of the biscuit is two-fold: had further information been provided
initially or when requested there would be
- less speculation needed to provide potential solutions, alternate or
otherwise
- less gnashing of teeth over misunderstandings generated by the
speculation

It is not about the OP being right or wrong as much as how the
question is asked and the details provided. I find it extremely
difficult to answer a question before the question is fully
understood. That is why I insist on 'debugging' requirements before
proceeding. Clarity is everything.

I appreciate your efforts and hopefully they will provide a suitable
solution for the OP.

regards
A.G.
 
J.B. Moreno said:
And that's a reasonable question, but it's no reason to put down the
OP's question. I have found the OP's refusal to answer that question
irritating...
Click to expand...

As you can see by some parts of this thread, it can go down tangents that I
don't want to waste my time on. The Name property of a Windows control,
used by way of trying to explain what I was looking for, for example. Or
questions about why the user would ever want to see a function name,
followed almost by requests to see my requirements document. But I do
appreciate any help, of course, so thank you.

This is not unique to this forum or even the internet.
 
Back
Top