Get method name programmatically

[Eugen Labun]

Hi all,

I would like to get the name of the current method programmatically (from within this method).

In Java I would do it via throwing exception and search in the stack trace.
But this is expensive (in terms of time, not in LoC). There will be hundreds of such calls.

Is there eventually a more effective solution for Scala?

Regards,
Eugen Labun

[Maxime Lévesque]

You don't need to throw and catch an excaption, you can use : 

 Thread.getStackTrace

I assume it's still pretty expensive though, and I don't know of a cheaper way.

[Randall R Schulz]

On Monday March 14 2011, Eugen Labun wrote:
> ...
> Eugen Labun

Perhaps we should start a new group / list, Scala-Dynamic,
for all the refugees from those other languages...

Randall Schulz

[Eugen Labun]

Thank you, Maxime,

this is still an improvement.

[Eugen Labun]

I'm not a refugee from dynamic languages. In principle I'm "strongly typed" :)

[Kevin Wright]

On 14 Mar 2011 13:14, "Eugen Labun" <la...@gmx.net> wrote:
>
> Hi all,
>
> I would like to get the name of the current method programmatically (from within this method).
>

Can I ask why?

If it's not for exception reporting, then there may be a better way...

[Eugen Labun]

I develop a parsing library. The idea is to automatically name each parser rule according to the
name of the defining method to (automatically) produce better debugging and error mesages.

[Jim Powers]

Wanting that kind of reflective information is not synonymous with
"dynamically typed language". Even in such languages reflection
coverage is spotty. For instance, getting the arity of a function in
Ruby (1.8.x) is not straight-forward.

--
Jim Powers

[Paul Phillips]

On 3/14/11 6:50 AM, Eugen Labun wrote:
> I develop a parsing library. The idea is to automatically name each
> parser rule according to the name of the defining method to
> (automatically) produce better debugging and error mesages.

It's a legit reason and it comes up all the time for me: I end up with
lots of code which for one reason or another looks like

val foo = something("foo", ...)

Clearly in these contexts it would be useful to be able to refer to the
name of what you are. Just because one of the duplications is in quotes
doesn't mean it's not pure duplication.

If you ponder the problem a moment, it is odd that we have this first
class construct "this" to refer to "the current class" but nothing for
the current method. The method is (already, but far more so in java 7)
a discrete unit of functionality. Given a way to refer to the current
method one could do interesting things like...

thisMethod.recurse(5) // immunized against name changes
thisMethod.name
thisMethod.alternatives
... your idea here!

[Jim Powers]

On Mon, Mar 14, 2011 at 9:54 AMm, Jim Powers <j...@casapowers.com> wrote:
> Wanting that kind of reflective information is not synonymous with
> "dynamically typed language".  Even in such languages reflection
> coverage is spotty.  For instance, getting the arity of a function in
> Ruby (1.8.x) is not straight-forward.

Correction:
Grr. getting the "correct" arity (including "splats" and block
arguments) is not straight-forward.

Enough on Ruby, back to Scala.

--
Jim Powers

[Jim Powers]

+1

This is on the roadmap right? ;-)

--
Jim Powers

[Maxime Lévesque]

You could use proxying :

  http://cglib.sourceforge.net/

along with thread local storage, probably (but not garanteed)  more efficient than getCurrentStack ...

[Kevin Wright]

Do you see any reason why this couldn't reasonably be prototyped via a plugin?

Ignoring recurse and alternatives for now, with the old chestnut that you'd want to synthesise methods after typing, it certainly looks like thisMethod.name would be easy enough to drop in directly after the parser phase.

--
Kevin Wright

gtalk / msn : kev.lee...@gmail.com

mail: kevin....@scalatechnology.com

vibe / skype: kev.lee.wright

quora: http://www.quora.com/Kevin-Wright
twitter: @thecoda

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Eugen Labun]

Paul, thank you, you described my situation exactly!

And yeah, it would be very interesting to have "thisMethod".

Where can I read more about new features of methods in Java 7? (Haven't heard anything about what
you've mentioned.)

[Eugen Labun]

Thank you, Maxime,

I will look into it.
(This will surely need some time.)

[Eugen Labun]

On 2011-03-14 15:18, Eugen Labun wrote:
> Where can I read more about new features of methods in Java 7? (Haven't heard anything about what
> you've mentioned.)

Found: that should be 'MethodHandle'

[Mark Harrah]

On Mon, 14 Mar 2011 06:59:04 -0700
Paul Phillips <pa...@improving.org> wrote:

> On 3/14/11 6:50 AM, Eugen Labun wrote:
> > I develop a parsing library. The idea is to automatically name each
> > parser rule according to the name of the defining method to
> > (automatically) produce better debugging and error mesages.
>
> It's a legit reason and it comes up all the time for me: I end up with
> lots of code which for one reason or another looks like
>
> val foo = something("foo", ...)
>
> Clearly in these contexts it would be useful to be able to refer to the
> name of what you are. Just because one of the duplications is in quotes
> doesn't mean it's not pure duplication.

This is a problem for me as well. A related problem for me is listing all such definitions in an object. I think addressing the two issues would make it possible to implement Enumeration without reflection, for example.

value x,y = Value
value z = Value(3)

translates to
val x = Value("x")
val y = Value("y")
val z = Value("z",3)
def values = Seq(x,y,z)

One could go further and write the above as:

value x,y,z(3)

-Mark

[√iktor Klang]

+1!

--
Viktor Klang,
Code Connoisseur
Work:   Scalable Solutions
Code:   github.com/viktorklang
Follow: twitter.com/viktorklang
Read:   klangism.tumblr.com

[Philippe Lhoste]

On 14/03/2011 14:14, Eugen Labun wrote:
> I would like to get the name of the current method programmatically (from within this method).

Note that in Scala (or other functional languages), the information might not be totally
accurate, as you can have lot of references to a method, allowing to call it with
alternative names...

def someMethod(n: Int): Int = { ... }
val otherMethod: Int => Int = someMethod

println(someMethod(11))
println(otherMethod(42))

In the stack traces, we see twice someMethod.

Or perhaps I am mixing methods and functions, the frontier is still blurry in my mind...

--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --

[Paul Phillips]

On 3/14/11 8:05 AM, Philippe Lhoste wrote:
> Note that in Scala (or other functional languages), the information
> might not be totally accurate, as you can have lot of references to a
> method, allowing to call it with alternative names...

No, those aren't methods.

> def someMethod(n: Int): Int = { ... }
> val otherMethod: Int => Int = someMethod

"otherFunction".

[Eugen Labun]

Yes, I should take care of many things if I stick with analysis of the stack trace solution.

E.g. how to split an entry from the stack trace into correct parts?

Actually I do it with the extractor

val MethodNameParts = """([\w$]*\.)+([^\(]+)(.*)""".r

used as: val MethodNameParts(path, name, rest) = methodName

Can I rely on the schema of this construction?
How should the parts be named more correctly?

E.g. is it a correct spliting or am I missing something:

entry: test$1line15$object$$iw$$iw$.(<console>:7)

parts: name: test$1
path: line15$object$$iw$$iw$.
rest: (<console>:7)

?

[Paul Phillips]

On 3/14/11 8:41 AM, Eugen Labun wrote:
> Yes, I should take care of many things if I stick with analysis of the stack trace solution.
>
> E.g. how to split an entry from the stack trace into correct parts?

I have a ton of code for this sort of thing, some of which is in trunk,
most of which isn't. Shoot, I had really meant to finish this for 2.9.
It basically works and is terribly useful, I just haven't put the
polish on the apple.

I put the branch in its current state on github. Look around the files
in this directory:

https://github.com/scala/scala/tree/funnel/src/compiler/scala/tools/funnel/

In terms of what's in trunk already, see Exceptional for a much reduced
preview of the above.

https://github.com/scala/scala/blob/master/src/compiler/scala/tools/nsc/util/Exceptional.scala

[Eugen Labun]

OK, I will look into. Thank you again, Paul!

Correction: the "entry" in the prev. post should be:
line15$object$$iw$$iw$.test$1(<console>:7)

[Eugen Labun]

Correction to the extractor:

val MethodNameParts = """((?:[\w$]*\.)+)([^\(]+)(.*)""".r

[Eugen Labun]

I must have been blind.
The stack trace consist of 'StackTraceElement's, which have 'getMethodName' and other useful
methods. No need to parse anything!

On 2011-03-14 16:49, Paul Phillips wrote:

[richard emberson]

Don't know if this is faster, but I've done this in the past:

import java.lang.management._
def getCallingFunctionName(depth: Int): String = {
val mxBean = ManagementFactory.getThreadMXBean
val threadInfo =mxBean.getThreadInfo(Thread.currentThread.getId,depth)
val elements = threadInfo.getStackTrace
elements(depth-1).getMethodName
}

--
Quis custodiet ipsos custodes

[Eugen Labun]

Thank you, Richard,

I will try it.

[Nils Kilden-Pedersen]

On Mon, Mar 14, 2011 at 12:37 PM, richard emberson <richard....@gmail.com> wrote:

Don't know if this is faster, but I've done this in the past:

import java.lang.management._
def getCallingFunctionName(depth: Int): String = {
 val mxBean = ManagementFactory.getThreadMXBean
 val threadInfo =mxBean.getThreadInfo(Thread.currentThread.getId,depth)
 val elements = threadInfo.getStackTrace
 elements(depth-1).getMethodName

}

Any reason to think that is faster than Thread.currentThread.getStackTrace?

[richard emberson]

This approach limits the size of the stack trace requested.
But, like I said, I don't know if its faster.

I also then cache the method name based upon the method
body (() => R) and look up the name from the cache on
subsequent calls.

--
Quis custodiet ipsos custodes

[Nils Kilden-Pedersen]

On Mon, Mar 14, 2011 at 3:33 PM, richard emberson <richard....@gmail.com> wrote:

This approach limits the size of the stack trace requested.

I see. I hadn't noticed that. Thanks.

[Adriaan Moors]

On Mon, Mar 14, 2011 at 2:14 PM, Eugen Labun <la...@gmx.net> wrote:

I would like to get the name of the current method programmatically (from within this method).

Is there eventually a more effective solution for Scala?

I think there might be a special kind of manifest that provides this kind of information in the near future (post 2.9.0 in any case).

cheers

adriaan

[Andrés Testi]

I agree! Could be something like:

def assertTrue(cond: Boolean)(implicit m: MethodManifest) = ....

- Andrés

[Eugen Labun]

Thank you, Adriaan,

this is a very good news! Looking forward to it.

--
Eugen

On 2011-03-15 17:23, Adriaan Moors wrote:

[Naftoli Gugenheim]

If there's some way to use objects instead of a current method then you could use its class name. Lift uses this technique to know the name of Mapper fields, and to back RequestVar etc.'s contents.

[Eugen Labun]

Naftoli, could you eventually point to the corresponding Lift code?
(Sorry, I'm not yet familiar with Lift)

[Naftoli Gugenheim]

Are you looking for the code that runs the reflection or demonstration code?

The former is here: https://github.com/lift/framework/blob/master/persistence/mapper/src/main/scala/net/liftweb/mapper/MetaMapper.scala (search for findMagicFields).

[Eugen Labun]

Thank you, Naftoli. I will look into.