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'.
# Returns the current method or method name
def calling(firstclass=false)
m = /\`([^\']+)\'/.match(caller(1).first)[1]
return ( firstclass ? method( m ) : m.intern )
end
Also, will a method like this be implemented in future Ruby?
Thanks,
T.
Hi,
In message "Re: Best name for "this method" ?" on Tue, 28 Sep 2004 08:45:59 +0900, "trans. (T. Onoma)" <transami@runbox.com> writes:
Also, will a method like this be implemented in future Ruby?
Possible. A good name for it is a must.
matz.
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'.
How about "me" ?
Hi --
On Tue, 28 Sep 2004, 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'.# Returns the current method or method name
def calling(firstclass=false)
m = /\`([^\']+)\'/.match(caller(1).first)[1]
return ( firstclass ? method( m ) : m.intern )
endAlso, will a method like this be implemented in future Ruby?
If so, I hope it won't have the boolean flag. I think those flags,
such as instance_methods(false), etc., are the most obscure, cryptic
thing in Ruby. I'd like to see them disappear.
David
--
David A. Black
dblack@wobblini.net
in C this is known as __FUNCTION__. so perhaps 'function'. this could be
o.k. if it were a method of Binding => Binding#function
also useful would be
Binding#functions
to return a list of the call stack function names
-a
On Tue, 28 Sep 2004, 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'.# Returns the current method or method name
def calling(firstclass=false)
m = /\`([^\']+)\'/.match(caller(1).first)[1]
return ( firstclass ? method( m ) : m.intern )
endAlso, will a method like this be implemented in future Ruby?
Thanks,
T.
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
In Javascript, there is 'caller' (the method which called the current method) and 'callee' (a pointer to the current method).
On Sep 27, 2004, at 5:45 PM, 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'.
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
Amen. I can _never_ get a meaningful, predictable result out of those
damn *methods(flag) methods! At least, not on purpose. I've thought
more than once about writing my own set of methods to wrap those.
Pity thought hasn't become action.
Gavin
On Tuesday, September 28, 2004, 10:09:30 AM, David wrote:
Hi --
On Tue, 28 Sep 2004, 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'.# Returns the current method or method name
def calling(firstclass=false)
m = /\`([^\']+)\'/.match(caller(1).first)[1]
return ( firstclass ? method( m ) : m.intern )
endAlso, will a method like this be implemented in future Ruby?
If so, I hope it won't have the boolean flag. I think those flags,
such as instance_methods(false), etc., are the most obscure, cryptic
thing in Ruby. I'd like to see them disappear.
Hi --
On Tue, 28 Sep 2004 Ara.T.Howard@noaa.gov wrote:
On Tue, 28 Sep 2004, 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'.
>
> # Returns the current method or method name
> def calling(firstclass=false)
> m = /\`([^\']+)\'/.match(caller(1).first)[1]
> return ( firstclass ? method( m ) : m.intern )
> end
>
> Also, will a method like this be implemented in future Ruby?
>
> Thanks,
> T.in C this is known as __FUNCTION__. so perhaps 'function'. this could be
o.k. if it were a method of Binding => Binding#function
Hmmmm... then we'd have proc, Proc, lambda, block, closure, method,
*and* function 
David
--
David A. Black
dblack@wobblini.net
Binding.of_caller? Could you explain this more? I'm not sure to what you are
referring.
Thanks,
T.
On Monday 27 September 2004 08:49 pm, Florian Gross wrote:
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.)
Actually, I agree with you too. Since it's just a flag, perhaps using
meaningful symbols would be better?
methods(:public)
methods(:private)
methods(:protected)
methods(:no_ancestors)
methods(:ancestors_only)
methods(:class) # same as self.class.methods ?
methods(:singleton)
And they could be combined:
methods(:private, :protected)
methods(:singleton, :private)
methods(:private, :no_ancestors)
Etc.
T.
On Monday 27 September 2004 08:09 pm, David A. Black wrote:
If so, I hope it won't have the boolean flag. I think those flags,
such as instance_methods(false), etc., are the most obscure, cryptic
thing in Ruby. I'd like to see them disappear.
Then what about #called for just the method name?
def my_method
p called
end
T.
On Monday 27 September 2004 08:49 pm, Florian Gross wrote:
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 )
> endPersonally, I'd dump the first-class logic and call it method_name. It
is easy enough to turn that into a Method anyway.
My initial reaction was that it's too much like self. But now that I've given
it some more thought it probably is an excellent choice.
1) It's a pronoun
2) It's very short
3) It has some semantic value, i.e. as in (me)thod
4) It not really used for anything else (AFAIK)
T.
On Monday 27 September 2004 08:01 pm, vruz 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'.How about "me" ?
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 )
endPersonally, 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
What about 'operator'?
T.
On Monday 27 September 2004 07:57 pm, Yukihiro Matsumoto wrote:
on Tue, 28 Sep 2004 08:45:59 +0900, "trans. (T. Onoma)" <transami@runbox.com> writes:
>Also, will a method like this be implemented in future Ruby?Possible. A good name for it is a must.
matz.
Nice idea. I'm considering putting a bit of effort into an API for
querying the methods of an object. It's an easy thing to do, but it's
gotta be done well. Anyway...
m = Methods["foo"] # -> Methods object
m.public
m.protected
m.private
m.singleton
m.no_ancestors
m.ancestors_only
m.class # name clash 
m.public(:no_ancestors)
m.singleton(:private)
m.query(:public, :no_ancestors)
m.query(:singleton, :private)
Then a similar thing for instance methods of a class/module.
m = InstanceMethods[String]
m.public
...
Just scratching for ideas at the moment. Send them in!!
Gavin
On Tuesday, September 28, 2004, 11:11:19 AM, trans. wrote:
On Monday 27 September 2004 08:09 pm, David A. Black wrote:
If so, I hope it won't have the boolean flag. I think those flags,
such as instance_methods(false), etc., are the most obscure, cryptic
thing in Ruby. I'd like to see them disappear.
Actually, I agree with you too. Since it's just a flag, perhaps using
meaningful symbols would be better?
methods(:public)
methods(:private)
methods(:protected)
methods(:no_ancestors)
methods(:ancestors_only)
methods(:class) # same as self.class.methods ?
methods(:singleton)
And they could be combined:
methods(:private, :protected)
methods(:singleton, :private)
methods(:private, :no_ancestors)
Hi --
On Tue, 28 Sep 2004, trans. (T. Onoma) wrote:
On Monday 27 September 2004 08:01 pm, vruz 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'.
>
> How about "me" ?My initial reaction was that it's too much like self. But now that I've given
it some more thought it probably is an excellent choice.1) It's a pronoun
2) It's very short
3) It has some semantic value, i.e. as in (me)thod
4) It not really used for anything else (AFAIK)
I think your initial reaction was right With things like this, I
usually run through in my mind what it would be like to teach it to a
new Rubyist. I think trying to explain "self" and "me" would be
awkward.
David
--
David A. Black
dblack@wobblini.net
touche. i humbly withdraw my nomination. 
-a
On Tue, 28 Sep 2004, David A. Black wrote:
Hmmmm... then we'd have proc, Proc, lambda, block, closure, method, *and*
function
EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
PHONE :: 303.497.6469
A flower falls, even though we love it;
and a weed grows, even though we do not love it. --Dogen
===============================================================================
Okay, I see. I did some research to understand. The problem I see with this is
that it might have too large an overhead --in effect creating a binding prior
to every method invocation. Is that so? On the other hand, I see no reason
for ‘self’ of caller not to be available.
T.
On Monday 27 September 2004 09:00 pm, trans. (T. Onoma) wrote:
On Monday 27 September 2004 08:49 pm, Florian Gross wrote:
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.)Binding.of_caller? Could you explain this more? I’m not sure to what you
are referring.
"trans. (T. Onoma)" <transami@runbox.com> schrieb im Newsbeitrag
news:200409272111.15070.transami@runbox.com...
> If so, I hope it won't have the boolean flag. I think those flags,
> such as instance_methods(false), etc., are the most obscure, cryptic
> thing in Ruby. I'd like to see them disappear.Actually, I agree with you too. Since it's just a flag, perhaps using
meaningful symbols would be better?methods(:public)
methods(:private)
methods(:protected)methods(:no_ancestors)
methods(:ancestors_only)methods(:class) # same as self.class.methods ?
methods(:singleton)And they could be combined:
methods(:private, :protected)
methods(:singleton, :private)
methods(:private, :no_ancestors)
Combining the results is the only advantage of this approach. Still I
prefer simple and short method implementations (which are less error prone
and often more efficient). So if you use symbols, change method names:
public_methods()
private_methods()
protected_methods()
local_methods()
inherited_methods()
drop: methods(:class) # same as self.class.methods ?
singleton_methods()
You can still combine these by concatenating invocation results. I think
usually this is not necessary
Kind regards
robert
On Monday 27 September 2004 08:09 pm, David A. Black wrote: