Best name for "this method"?

[Florian_Gross]

trans. (T. Onoma) wrote:

···

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 )
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.

Then what about #called for just the method name?

  def my_method
    p called
  end

Why not method_name? called() is a bit ambiguous IMHO...

Regards,
Florian Gross

[T_Onoma]

Did anyone ever respond to you? If no, we's very sorry.

Actually Ruby has something quite like thisContext called a Binding. At least
I think they would be the same according to your description. (Yes, the
Smalltalk name is probably better.)

Bindings are a bit heavy weight (I think) for just getting the current method
name. Although, it would be cool if Bindings had little to no cost, then we
could use the heck out of em.

Anyone know what the costs associated with Bindings are more exactly?

T.

···

On Tuesday 28 September 2004 02:44 am, Jim Haungs wrote:

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!)

[Markus]

I don't like it. "Operator" has a pretty specific set of
connotations, both in math and computer science; they are:

      * generally given symbols in preference to names
      * parsed according to rules of precedence (e.g. MDAS) and
        associativity
      * narrow in definition or "algorithmically regular" as it is
        sometimes put
      * almost never have side-effects

    This use would break most of them.
    Things like "+" or "grad" (typically represented by a downward
pointing equilateral triangle) are operators. Most methods aren't.

-- Markus

···

On Sat, 2004-10-02 at 16:25, trans. (T. Onoma) wrote:

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.
>
What about 'operator'?

[T_Onoma]

I understand. Yet I can think of worse things to explain, like pg. 216 - 219
of my pickaxe, Variables and Constants Boy, it would be nice if more of
those were “classified” (and I feel likewise about a number of Kernel methods
too).

T.

···

On Monday 27 September 2004 09:38 pm, David A. Black wrote:

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.

[Markus]

> >
> > 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)

     Not seriously floating this (unless everyone loves it) but the
traditional way of referring to the present routine in code reviews (and
even in comments) is "we" as in "we sort the array first, so that when
we look through it we see the likely prospects..."

    -- MarkusQ

[vruz]

> 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.

"me" should be pretty mnemotechnical for method
I would find it hard to forget that way

--- vruz

[Florian_Gross]

trans. (T. Onoma) wrote:

Binding.of_caller? Could you explain this more? I'm not sure to what you
are referring.

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.

Why? As you can see from my trace_func implementation Ruby already knows how to fetch the binding on demand (via ruby_frame->prev) -- it just doesn't provide a way to do it from within Ruby.

Regards,
Florian Gross

[Gavin_Sinclair]

I completely disagree, Robert. Lots of related methods is a code smell
to my nose. Elegant solutions are generally well factored, rather than
expanded all over the top level. One should aim to keep like things
together, and different things apart.

There are two possible factorings. Have Object#methods return a
specialised object, thus:

  foo.methods.private
  foo.methods.all
  foo.methods.new
  foo.methods.singleton
  foo.methods[:new, :protected] # if you need combination
  # etc.

The other possible factoring is as above:

  foo.methods(:new)
  foo.methods(:private)
  foo.methods(:singleton, :private)
  # etc.

Aesthetically, I think I prefer the top one. But even the second one
is far preferable to the current state of Ruby, to my mind.

In general, you dislike using symbolic arguments to tune a method's
behaviour. I like it, and consider it quite consistent with the
general practices of good programming.

Cheers,
Gavin

···

On Tuesday, September 28, 2004, 5:49:21 PM, Robert wrote:

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()

[Austin_Ziegler5 (Austin Ziegler)]

This sounds like a lovely RCR candidate, Robert

-austin

···

On Tue, 28 Sep 2004 16:49:21 +0900, Robert Klemme <bob.news@gmx.net> wrote:

"trans. (T. Onoma)" <transami@runbox.com> schrieb im Newsbeitrag
news:200409272111.15070.transami@runbox.com...

> 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)

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

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca
: as of this email, I have [ 6 ] Gmail invitations

[T_Onoma]

Two downsides of method_name. The lesser is that it is not brief. The grater
is that it indicates nothing about the fact that it is _this_, the current,
method's name.

T.

···

On Tuesday 28 September 2004 04:19 am, Florian Gross wrote:

Why not method_name? called() is a bit ambiguous IMHO...

[T_Onoma]

Fair enough. How about another:

  moniker

T.

···

On Saturday 02 October 2004 08:01 pm, Markus wrote:

     I don't like it. "Operator" has a pretty specific set of
connotations, both in math and computer science; they are:

      * generally given symbols in preference to names
      * parsed according to rules of precedence (e.g. MDAS) and
        associativity
      * narrow in definition or "algorithmically regular" as it is
        sometimes put
      * almost never have side-effects

    This use would break most of them.
    Things like "+" or "grad" (typically represented by a downward
pointing equilateral triangle) are operators. Most methods aren't.

[T_Onoma]

Do we now?

T.

···

On Monday 27 September 2004 11:46 pm, Markus wrote:

 Not seriously floating this (unless everyone loves it) but the

traditional way of referring to the present routine in code reviews (and
even in comments) is “we” as in “we sort the array first, so that when
we look through it we see the likely prospects…”

[Robert]

"vruz" <horacio.lopez@gmail.com> schrieb im Newsbeitrag
news:6b809bd804092722465fa1de66@mail.gmail.com...

> > 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.

"me" should be pretty mnemotechnical for method
I would find it hard to forget that way

Perl name clash alarm! Seriously, I don't think "me" is appropriate. I
would usually expect it to denote an instance and not a method. Also, it
sounds like an alias for "self" rather than "this method".

Kind regards

    robert

[Robert]

"Gavin Sinclair" <gsinclair@soyabean.com.au> schrieb im Newsbeitrag
news:1801770404777.20040928194159@soyabean.com.au...

>> 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()

I completely disagree, Robert. Lots of related methods is a code smell
to my nose. Elegant solutions are generally well factored, rather than
expanded all over the top level. One should aim to keep like things
together, and different things apart.

There are two possible factorings. Have Object#methods return a
specialised object, thus:

  foo.methods.private
  foo.methods.all
  foo.methods.new
  foo.methods.singleton
  foo.methods[:new, :protected] # if you need combination
  # etc.

The other possible factoring is as above:

  foo.methods(:new)
  foo.methods(:private)
  foo.methods(:singleton, :private)
  # etc.

Aesthetically, I think I prefer the top one. But even the second one
is far preferable to the current state of Ruby, to my mind.

In general, you dislike using symbolic arguments to tune a method's
behaviour. I like it, and consider it quite consistent with the
general practices of good programming.

Agree and disagree: after thinking a bit about the issue I think that
those symbol arguments are not as bad as I thought earlier because they
can be viewed as a filter criterion. Even if the implementaiton of
"method" would delegate to several other methods this seems ok to me.

I still have problems with the last, very general statement, unless you
mean only slight changes in behavior by "tune": when arguments (whatever
type they have) are used to vastly change a method's behavior then a
solution with several methods is superior: it's more modular, makes life
of sub class implementors easier who may need to override just one of
these methods, those several methods are likely shorter and thus less
susceptible to errors than the all-in-one method, there is likely a
performance gain because the code that figures what to do is obsolete etc.

I think my general line here would be, that "tuning" by arguments (i.e.
small changes in behavior) is ok, but that it becomes more problematic the
greater the differences are. There is no single measurable point that can
be used as a criterium in this case. As always the situation at hand must
be careful evaluated to find the most appropriate solution. It's
certainly an advantage to know both approaches and the pros and cons of
them.

Gavin, thanks for helping to sort this out!

Kind regards

    robert

···

On Tuesday, September 28, 2004, 5:49:21 PM, Robert wrote:

[T_Onoma]

For this approach, I think combinations would be better like:

  foo.methods { |m| m.private | m.singleton }
  foo.methods { |m| m.private + m.public }

But I think it might be a bit much to have a whole new class for this.

Sometimes I really wish symbolic keyed hashes were accessable like object
methods:

   h = { a: 1, b: 2 }
   h.a #=> 1
   h.b #=> 2

That would be sweet. And would make the above possible without a new class. I
know, method name clash is bad --and there's little one can do to get around
it. Perhaps alternate notation?

   h:a
   h:b

But I digress.

T.

···

On Tuesday 28 September 2004 05:44 am, Gavin Sinclair wrote:

There are two possible factorings. Have Object#methods return a
specialised object, thus:

  foo.methods.private
  foo.methods.all
  foo.methods.new
  foo.methods.singleton
  foo.methods[:new, :protected] # if you need combination
  # etc.

[T_Onoma]

Well, that's my question. Does it just retrieve a reference or does it have to
create the binding? If it's just grabbing a reference to an already existing
binding, that's fine, but then I don't see why using set_trace_function
should slow a program down as much as it does. So I'm guessing it has to
create a binding. Although ruby_frame->prev suggests it already exists.

I just don't know the internals well enough, and am wondering.

T.

···

On Tuesday 28 September 2004 04:29 am, Florian Gross wrote:

trans. (T. Onoma) wrote:
>>Binding.of_caller? Could you explain this more? I'm not sure to what you
>>are referring.
>
> 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.

Why? As you can see from my trace_func implementation Ruby already knows
how to fetch the binding on demand (via ruby_frame->prev) -- it just
doesn't provide a way to do it from within Ruby.

[Robert]

"Austin Ziegler" <halostatue@gmail.com> schrieb im Newsbeitrag news:9e7db91104092805256250c78d@mail.gmail.com...

···

On Tue, 28 Sep 2004 16:49:21 +0900, Robert Klemme <bob.news@gmx.net> > wrote:

"trans. (T. Onoma)" <transami@runbox.com> schrieb im Newsbeitrag
news:200409272111.15070.transami@runbox.com...

> 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)

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

This sounds like a lovely RCR candidate, Robert

.... with auto rejection? Nah, thanks, no DOA needed.

    robert

[T_Onoma]

This line's got me thinking... How does one define a class constructor? For
example Hash can be use like this:

  Hash[:a=>1,:b=>2 ]

And then I start to wonder why we can't just use the class name like a method?

  Hash(:a=>1, :b=>2)

Of course, I also think the same of Procs themselves, and having to use call
(or ):

  myproc = proc{2+2}
  myproc() #=> 4

The potential name clashes don't seem a big enough blooper to me, but perhaps
I have forgotten another reason.

Anyway, once again I digress. My original point was simply this: Would it
behoove us to extend the construct on hashes to accept multiple
parameters? E.g.

  h = { :a => 1, :b => 2, :c => 2 }
  h[:a, :c] #=> [1,2]

This would make Gavin's above method notation nicely workable without a
special class.

T.

···

On Tuesday 28 September 2004 05:44 am, Gavin Sinclair wrote:

foo.methods[:new, :protected] # if you need combination

--
( o _ カラチ
// trans.
/ \ transami@runbox.com

I don't give a damn for a man that can only spell a word one way.
-Mark Twain

[gabriele_renzi]

trans. (T. Onoma) ha scritto:

···

On Tuesday 28 September 2004 04:19 am, Florian Gross wrote:

Why not method_name? called() is a bit ambiguous IMHO...

Two downsides of method_name. The lesser is that it is not brief. The grater is that it indicates nothing about the fact that it is _this_, the current, method's name.

I think the groovy guys name it 'callee' or something similar.
I remember seeing it as a way to write recursive procs, but I may be wring.

[T_Onoma]

It occurs to me that technically the method name should be called the
'message', shouldn't it?

T.

···

On Tuesday 28 September 2004 08:52 pm, trans. (T. Onoma) wrote:

On Tuesday 28 September 2004 04:19 am, Florian Gross wrote:
> Why not method_name? called() is a bit ambiguous IMHO...

Two downsides of method_name. The lesser is that it is not brief. The
grater is that it indicates nothing about the fact that it is _this_, the
current, method's name.