I'll preface this with saying I don't know Ruby yet as well as I know
Smalltalk, so please correct any fine points I get wrong.

In Smalltalk, the calling context is called "thisContext" because it
can be either a method or a block. And it returns an actual context
object, which are represented by a class in Smalltalk, but which are
not (as far as I can tell) reified in Ruby.

So if you implemented it in Ruby, you'd have to decide whether it
referred to the block context or the enclosing method context,
and you'd have to invent a reification of the dynamic execution
context, as the method name by itself isn't very useful.

I'd certainly think twice about adding it to the language. What you
explicitly leave out of a language is as important as what you put in.

In 20+ years of reading and writing Smalltalk, I've hardly ever used
it or seen it used except for writing debuggers and similar tools that
deal with dynamic execution state.

I wanted to include some statistics on its use in Smalltalk, but
unfortunately, it's not a true message send in VisualWorks; it's
inlined by the compiler. So you'd have to write some bytecode scanning
code to find where it's called (which might be fun!)

On Tue, 28 Sep 2004 02:46:34 +0200, Florian Gross <flgr / ccan.de>
wrote:

>trans. (T. Onoma) wrote:
>
>> Wondering what the conscensus is on the best name for "this method". Right now 
>> I'm using #calling, taking after #binding, but I'm not so sure about it. I've 
>> also considered #this or #thus, to be more along the lines of 'self'.
>
>JavaScript uses callee for the first-class version.
>
>>   # Returns the current method or method name
>>   def calling(firstclass=false)
>>     m = /\`([^\']+)\'/.match(caller(1).first)[1]
>>     return ( firstclass ? method( m ) : m.intern )
>>   end
>
>Personally, I'd dump the first-class logic and call it method_name. It 
>is easy enough to turn that into a Method anyway.
>
>> Also, will a method like this be implemented in future Ruby?
>
>I'm not sure about this. (Is it needed frequently?) But right now I'd 
>prefer Binding.of_caller to be in Ruby itself. After all it is needed 
>for wrapping eval() and it can not be done with a pretty interface in 
>plain Ruby. (It can be done in Ruby if you turn it inside out, e.g. make 
>it yield a value instead of returning it.)
>
>> Thanks,
>> T.
>
>Regards,
>Florian Gross