I just looked at matz’ slides and I don’t have a clear understanding
of ho9w this is suposed to work.
Possibly this has been explained verbosely, But I can’t get it from
the slide.
So, this is the example:
class Foo
def foo(*args) #1
p 'foo’
end
def foo:pre (*args ) #2
p 'pre’
end
def foo:post (*args) #3
p 'post’
end
def foo:wrap (*args) #4
p 'wrap pre’
super
p 'wrap post’
end
end
now: what are pre post and wrap?
Are this just generic (casual) names for the wrapping functions? (so
we could have def foo:bar)
Are they wrapping idioms ?
if true
what do they are for? Do the work as in :
pre called before the method
post called after the method
wrap could call super and get the old method
I suppose pre and post are actually useless this way, cause they
can be emulated with foo:wrap()
or do the work as
pre wraps the original method
post wraps the latest wrapping of the method
wrap … ?
The slide demonstrates it adequately. Given the above code:
Foo.new.foo
Output:
wrap pre
pre
foo
post
wrap post
Gavin
···
On Monday, November 17, 2003, 6:22:18 PM, gabriele wrote:
I just looked at matz’ slides and I don’t have a clear understanding
of ho9w this is suposed to work.
Possibly this has been explained verbosely, But I can’t get it from
the slide.
So, this is the example:
class Foo
def foo(*args) #1
p ‘foo’
end
def foo:pre (*args ) #2
p ‘pre’
end
def foo:post (*args) #3
p ‘post’
end
def foo:wrap (*args) #4
p ‘wrap pre’
super
p ‘wrap post’
end
end
The slide demonstrates it adequately. Given the above code:
Foo.new.foo
Output:
wrap pre
pre
foo
post
wrap post
This is a feature from CLOS that allows you to add hooks to arbitrary
methods. The names ‘pre’, ‘post’ and ‘wrap’ are predefined and can’t be
changed. This isn’t a generic way to sort of chain methods together;
it’s sort of AOP-lite. For any method ‘foo’ you can define any
combination of foo:pre, foo:post and foo:wrap. According to Matz, you
can’t change the parameters in a pre, can’t change the return value in a
post, but you CAN do both in a wrap. The output snippet above shows the
order of calls if you define all three.
Joey
···
On Monday, November 17, 2003, 6:22:18 PM, gabriele wrote:
“Gavin Sinclair” gsinclair@soyabean.com.au schrieb im Newsbeitrag
news:1174425281.20031117234546@soyabean.com.au…
I just looked at matz’ slides and I don’t have a clear understanding
of ho9w this is suposed to work.
Possibly this has been explained verbosely, But I can’t get it from
the slide.
So, this is the example:
class Foo
def foo(*args) #1
p ‘foo’
end
def foo:pre (*args ) #2
p ‘pre’
end
def foo:post (*args) #3
p ‘post’
end
def foo:wrap (*args) #4
p ‘wrap pre’
super
p ‘wrap post’
end
end
I find the “super” a bit strange here. It looks like it was implied that
for all methods “foo” there is an implicit “foo:wrap” defined by the Ruby
runtime in a super class of the actual class. I’d prefer another keyword,
such as “previous”, “original” or so since the semantics differ. Or did I
get the meaning of “super” in this context wrong?
Regards
robert
···
On Monday, November 17, 2003, 6:22:18 PM, gabriele wrote:
I’m dumb I can admit thois
But, This could work both with idea #2 or #3.
The point is: if #2 is right (pre is called before the method. post is
called after the real method. wrap can call super.) what is the need
for pre and post? thay can be easily done transparently with wrap?
Does foo:post add itself to the first foo() definition or to the
latest redefinition?
what is the ‘method resolution order’ for method wrapping?
wrap->post->pre?
pre->post->wrap?
latest-definition-wins ?
if I did:
class Foo
def foo:wrap (*args) #4
p ‘wrap pre’
super
p ‘wrap post’
end
def foo(*args) #1
p ‘foo’
end
def foo:pre (*args ) #2
p ‘pre’
end
def foo:post (*args) #3
p ‘post’
end
end
Foo.new.foo would give the same output or would it give
there was already a working implementation of method wrapping… google
for
‘how I’d like method $x to work’
$x is something like ‘wrapping’ ‘hook’ ‘decoration’
I find the "super" a bit strange here. It looks like it was implied that
for all methods "foo" there is an implicit "foo:wrap" defined by the Ruby
runtime in a super class of the actual class.
well, I've not understood
super is in Foo#foo:wrap : this mean that if ruby call foo:wrap
then it exist at least the method Foo#foo which will be called latter
super, in this case, just assume that it exist another wrapper or the
original method.
I'd prefer another keyword,
such as "previous", "original" or so since the semantics differ.
call-next-method :-)))
Or did I
get the meaning of "super" in this context wrong?
The point is: if #2 is right (pre is called before the method. post is
called after the real method. wrap can call super.) what is the need
for pre and post? they can be easily done transparently with wrap?
Based on what I heard Matz say during the presentation, you are correct
that the ‘pre’ and ‘post’ methods’ behavior can be emulated with the
‘wrap’ method, i.e. this:
class Foo
def foo; p "foo"; end
def foo:pre; p "pre"; end
def foo:post; p "post"; end
end
and this:
class Foo
def foo
p "foo"
end
def foo:wrap
p "pre"
result = super
p "post"
result
end
end
would produce equivalent results.
Does foo:post add itself to the first foo() definition or to the
latest redefinition?
This was not specified (I think).
what is the ‘method resolution order’ for method wrapping?
wrap->post->pre?
pre->post->wrap?
latest-definition-wins?
Not sure I understand. “wrap” (if it exists) is the entry point, so it
has the first shot. Inside foo:wrap, if you call super (i.e. invoke the
wrapped method), it will call foo:pre (if it exists), then foo, then
foo:post (if it exists).
if I did:
class Foo
def foo:wrap (*args) #4
p ‘wrap pre’
super
p ‘wrap post’
end
def foo(*args) #1
p ‘foo’
end
def foo:pre (*args ) #2
p ‘pre’
end
def foo:post (*args) #3
p ‘post’
end
end
Foo.new.foo would give the same output or would it give
pre
wrap pre
foo
wrap post
post
?
For this example, Foo.new.foo would print:
wrap pre
pre
foo
post
wrap post
sorry for being stupid
Not stupid. And hopefully I haven’t given you bad information here
there was already a working implementation of method wrapping… google
for
‘how I’d like method $x to work’
$x is something like ‘wrapping’ ‘hook’ ‘decoration’
First of all, I will be happy with whatever Matz
decides. I will never flame the one who gave us Ruby.
I’m a little bothered by the use of ‘super’ also.
I once suggested ‘prior’; but I can (now) see that
using super does not introduce ambiguity.
It strikes me that wrap is really the only one
necessary. It could do all the work of pre and post.
Yet I suppose the others are good from the standpoint
of clarity.
I’m a little bothered that ‘post’ is not able to
know the return value of the method even though the
method has returned. (In theory we could use a call
to super that simply accessed the return value rather
than making a real call.) This is a motivation for
me to use wrap more often than post.
I find the “super” a bit strange here. It looks like it was implied
that
for all methods “foo” there is an implicit “foo:wrap” defined by the
Ruby
runtime in a super class of the actual class.
well, I’ve not understood
super is in Foo#foo:wrap : this mean that if ruby call foo:wrap
then it exist at least the method Foo#foo which will be called latter
super, in this case, just assume that it exist another wrapper or the
original method.
Yeah, but “super” generally refers to the same method defined in another
class up the inheritance hierarchy. That’s a chain different from the
wrapping chain.
I'd prefer another
keyword,
such as “previous”, “original” or so since the semantics differ.
call-next-method :-)))
or the even more typing friendly “invoke-next-wrapper-or-original-method”
:-)))
(Sorry, I couldn’t find something more longish.)
Or
did I
get the meaning of “super” in this context wrong?
probably,
Not from what you wrote: “super” invokes whatever is next in the wrapping
chain at whose end the original method resides. Thanks anyway.
It strikes me that wrap is really the only one
necessary. It could do all the work of pre and post.
Yet I suppose the others are good from the standpoint
of clarity.
A similar argument might be made for attr_accessor
making attr_reader & attr_writer unnecessary.
OK, there’s a ton of reasons why “that’s not the same
thing” (the best reason I can think of is that “they’re
not the same thing”;).
Whereas attr_* contains overlapping functionality,
hooking doesn’t appear to suffer in the same way.
Wrap is a controlling ‘outer’ wrap. The combination of
pre/post would be a benign ‘inner’ wrap. Benign in the
sense that you could safely assume that you wouldn’t
accidentally be changing the program’s logic.
Here (#+#) is the statement I add when I’m about to wreck logic:
class Roo
def r
7 * 6
#+# print 'r done … ’
end
end
p Roo.new.r # → 42
#+# p Roo.new.r # → r done … nil
If I understand :post, I should be able to add the method by:
class Roo
def r:post
print 'r done … ’
end
end
p Roo.new.r # → r done … 42
I’m a little bothered that ‘post’ is not able to
know the return value of the method even though the
method has returned.
But if :wrap is also defined, its back-end is about to get
control. If you want to know the return value, the only
sensible place to find out is in :wrap because you might
leave it as it is, or change it, and it can’t(?) be
changed any later.
Just my thoughts.
Hal
I’m just adding by trivial example that :pre or :post will
be better to use when :wrap might be over-kill.
Now how do you see that super don’t follow the inheritence
hierarchy ?
In the example, matz use only one class, difficult to speak
about inheritence with only one class
So the meaning of super varies when used in the wrap context.
What will be the meaning of super when used in foo:pre or
foo:post? While I kind of like the hook scheme I am not sure
I if like this C++/Java-ish keyword overloading.
