Super, aliases, defadvice, AOP, and so on

ruby-talk
1

Hello, all.

I’m reopening an issue I brought up
once before, just to make sure it
isn’t forgotten or under-explored.

Actually the thing I brought up
opened up a wider field of discussion,
and that’s what interests me.

Think for a moment about why we have
the keyword “super” – it’s a way of
distinguishing between the current
method and the one in the parent, but
it’s also a convenient shorthand that
does not depend on the method name.

I once proposed a keyword “prior” that
would refer to the old definition of a
method that was being replaced. This
would make unnecessary the idiom of
explicitly creating an alias and then
calling the old method by name.

But Matz replied (I’m paraphrasing)
that this was a part of a more general
problem, and that something like Lisp’s
defadvice was the answer.

Disclaimer: I don’t know Lisp and I know
little about AOP. But it seems likely to
me that this is where AOP gets its odd
usage of the word “advice.”

But this whole concept interests me. If
Ruby had suitable operations built in, it
could make AOP much easier, I think; not
to mention certain kinds of tools such as
debuggers and profilers.

I’m sure nothing like this will come about
until Rite at the earliest, however.

But I don’t consider it too early to speculate.
So: How does Lisp’s defadvice work? How should
something similar in Ruby work?

Matz, Dave, others?

Hal

2

Hi,

···

In message “super, aliases, defadvice, AOP, and so on” on 03/05/21, “Hal E. Fulton” hal9000@hypermetrics.com writes:

But I don’t consider it too early to speculate.
So: How does Lisp’s defadvice work? How should
something similar in Ruby work?

Matz, Dave, others?

It’s reference on my blog (but it’s in Japanese). And I have to
confess I have no final answer to your latter question.

						matz.
3

Hi –

Think for a moment about why we have
the keyword “super” – it’s a way of
distinguishing between the current
method and the one in the parent, but
it’s also a convenient shorthand that
does not depend on the method name.

I once proposed a keyword “prior” that
would refer to the old definition of a
method that was being replaced. This
would make unnecessary the idiom of
explicitly creating an alias and then
calling the old method by name.

But Matz replied (I’m paraphrasing)
that this was a part of a more general
problem, and that something like Lisp’s
defadvice was the answer.

I don’t know about defadvice either, but a thought or two anyway:

‘prior’ might have a usefulness, but it would not be a drop-in
replacement for what alias currently does (which of course is also
very different from what super does). alias’ing a method makes that
method callable in a general way, so:

class A
def x; end
end

class B
alias :y :x
def z; y; end # ‘prior’ would be meaningless here
end

I have some instinct that tells me that a method cannot, as a general
matter, “know” that it is replacing an existing method (because it may
or may not be, depending on dynamically evaluated conditions), but I
can’t quite think my way through it. Perhaps I’ll try to babelfish
thing with Matz’s weblog :slight_smile:

David

···

On Wed, 21 May 2003, Hal E. Fulton wrote:

–
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

4

If you will point me to that, I will at least
try to use babelfish or something. (With Japanese
text, I find that to be about 60% informative
and 40% entertaining.)

It appears from everyone’s silence that no one
wants to discuss this right now. Eventually I
will bring it up again, because it interests me
greatly and I think it is important.

Thanks,
Hal

···

----- Original Message -----
From: “Yukihiro Matsumoto” matz@ruby-lang.org
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, May 21, 2003 3:53 AM
Subject: Re: super, aliases, defadvice, AOP, and so on

In message “super, aliases, defadvice, AOP, and so on” > on 03/05/21, “Hal E. Fulton” hal9000@hypermetrics.com writes:

But I don’t consider it too early to speculate.
So: How does Lisp’s defadvice work? How should
something similar in Ruby work?

Matz, Dave, others?

It’s reference on my blog (but it’s in Japanese). And I have to
confess I have no final answer to your latter question.

5

I don’t know about defadvice either, but a thought or two anyway:

‘prior’ might have a usefulness, but it would not be a drop-in
replacement for what alias currently does (which of course is also
very different from what super does). alias’ing a method makes that
method callable in a general way, so:

[snip]

I’m not interested in a drop-in replacement for
alias, as such. I’m interested in a standard,
simplified way to extend the functionality of
an existing method – which we currently do by
aliasing the old method, redefining it, and
invoking the alias from within the new method.

Hmm, I’ll bet something like this can be done
in Ruby as-is (thinking, thinking…).

I have some instinct that tells me that a method cannot, as a general
matter, “know” that it is replacing an existing method (because it may
or may not be, depending on dynamically evaluated conditions), but I
can’t quite think my way through it. Perhaps I’ll try to babelfish
thing with Matz’s weblog :slight_smile:

Well, I’m in hesitant disagreement.

The interpreter certainly can “know” that a method
is being redefined; and in keeping with Ruby’s
reflective nature, I’d like to see that knowledge
available to the program. At least, I think I would!

And yes, we’d have to deal with situations where
the feature was used meaninglessly (both static
and dynamic); just as it’s possible to use “super”
in a context that makes it meaningless. (In many
cases, this will be caught at so-called “compile
time”; but my gut tells me we could contrive a
scenario where it couldn’t be determined until
runtime).

Hal

···

----- Original Message -----
From: dblack@superlink.net
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Wednesday, May 21, 2003 9:35 AM
Subject: Re: super, aliases, defadvice, AOP, and so on

6

Hi,

···

In message “Re: super, aliases, defadvice, AOP, and so on” on 03/05/21, “Hal E. Fulton” hal9000@hypermetrics.com writes:

It’s reference on my blog (but it’s in Japanese). And I have to
confess I have no final answer to your latter question.

If you will point me to that, I will at least
try to use babelfish or something. (With Japanese
text, I find that to be about 60% informative
and 40% entertaining.)

Try Matzにっき(2003-05-13)
and Matzにっき(2003-05-14)

						matz.
7

It appears from everyone’s silence that no one
wants to discuss this right now. Eventually I
will bring it up again, because it interests me
greatly and I think it is important.

···

----- Original Message -----
From: “Hal E. Fulton” hal9000@hypermetrics.com

I thought it had the potential to be the most interesting thread we’ve seen
in quite a while! However, I personally don’t have much to say about it.
For one thing, I don’t know anything about defadvice or AOP, and what I have
seen about AOP was so language specific that it was not at all clear how
much of what I was seeing was AOP and how much was just Java scaffolding.
Are there any Ruby-centric explanations of AOP?

As far as super, prior, etc… I’m not sure that I have ever wanted to
access a method that I have redefined in the same class (thus obliterating
the original), but I definitely have wanted to access methods in base
classes which have been shadowed in subclasses (and which obviously still
exist in the base classes). You can use super', but that only works from inside shadowing method, and it only takes you one level up. I still wish I could do something likeObject::inspect’ in C++… but I don’t know what
the Ruby would look like. As I see it, this is strictly a superset of what
`super’ already does.

Chris

8

Hi –

From: dblack@superlink.net

I have some instinct that tells me that a method cannot, as a general
matter, “know” that it is replacing an existing method (because it may
or may not be, depending on dynamically evaluated conditions), but I
can’t quite think my way through it. Perhaps I’ll try to babelfish
thing with Matz’s weblog :slight_smile:

Well, I’m in hesitant disagreement.

The interpreter certainly can “know” that a method
is being redefined; and in keeping with Ruby’s
reflective nature, I’d like to see that knowledge
available to the program. At least, I think I would!

I guess what I mean is that in writing a method, the person writing it
may or may not know, and therefore not know whether to use ‘prior’.
Example scenario still percolating somewhere in brain :slight_smile:

And yes, we’d have to deal with situations where
the feature was used meaninglessly (both static
and dynamic); just as it’s possible to use “super”
in a context that makes it meaningless. (In many
cases, this will be caught at so-called “compile
time”; but my gut tells me we could contrive a
scenario where it couldn’t be determined until
runtime).

Actually I think those are usually caught at runtime. It’s
essentially a method call, and the method either is or isn’t there:

irb(main):001:0> class A; def x; super; end; end
=> nil
irb(main):002:0> a = A.new
=> #<A:0x401a12e4>
irb(main):003:0> a.x
NameError: super: no superclass method `x’

David

···

On Thu, 22 May 2003, Hal E. Fulton wrote:

----- Original Message -----

–
David Alan Black
home: dblack@superlink.net
work: blackdav@shu.edu
Web: http://pirate.shu.edu/~blackdav

9

In article 1053527539.479012.23088.nullmailer@picachu.netlab.jp,

···

Yukihiro Matsumoto matz@ruby-lang.org wrote:

Hi,

In message “Re: super, aliases, defadvice, AOP, and so on” > on 03/05/21, “Hal E. Fulton” hal9000@hypermetrics.com writes:

It’s reference on my blog (but it’s in Japanese). And I have to
confess I have no final answer to your latter question.

If you will point me to that, I will at least
try to use babelfish or something. (With Japanese
text, I find that to be about 60% informative
and 40% entertaining.)

Try Matzにっき(2003-05-13)
and Matzにっき(2003-05-14)

  					matz.

The last part of that entry on hooks, babelfish translates to:

“So, it is scurvy the above define_method similar, well, that, it is
fault.”

So apparently some vitamin C is lacking.

Phil

10

and Matzにっき(2003-05-14)

Mix this with [ruby-talk:53186], and you have

svg% cat b.rb
#!./ruby
module M
   def initialize:hook(a)
      p "M::hook #{a.inspect}"
      super
   end
end

class A
   include M
   def initialize(a)
      p "A : #{a}"
   end
end

module N
   def initialize:hook(a)
      p "N::hook #{a}"
      super 12
   end
end

class B < A
   class << self
      def allocate:hook
         p "allocate:hook"
         super
      end
   end
   include N
   def initialize(a)
      @a = a
      p "B#initialize"
      super
   end
end

puts "======================="
p B.new(24)
puts "======================="
p A.new(36)

class B
   class << self
      undef allocate:hook
   end
   undef initialize:hook
end

puts "======================="
p B.new(24)
puts "======================="
p A.new(36)
svg%

svg% b.rb

···

=======================
"allocate:hook"
"N::hook 24"
"M::hook 12"
"B#initialize"
"A : 12"
./b.rb:39: warning: invalid inspect_tbl value
#<B:0x40098d2c @a=12>

"M::hook 36"
"A : 36"
#<A:0x40098bd8>

"B#initialize"
"A : 24"
#<B:0x40098ad4 @a=24>

"M::hook 36"
"A : 36"
#<A:0x40098a20>
svg%

I still don't like it

Guy Decoux