Do you remember the discussion about monitor-functions and
Well, I’ve completely rewritten this Module#wrap_method. It
should be more robust now: thread-safety, better execution
order of recursively wrapped methods, better execution order of
I added some convenience methods as well: Module#pre_condition
and Module#post_condition. These are really easy to use!
The article and the code are here:
Please, read it, both the article and the implementation,
especially the implementation, read it again, think about it,
test it, analyze it, use it and shoot.
But do not benchmark it… ;]
Erik V. - http://www.erikveen.dds.nl/
I had a discussion with a friend. A Java guy. He wants the
arguments of a method call being checked. “I want the first one
to be an Integer. And the second one is a String. Period.” No
discussion. I explained our duck-typing paradigm. He’s not
convinced. He thinks Java. So, he gets Java.
Lets check the types of the arguments of a method call!
(Well, this article is not about type checking at all. It’s
about how to implement such a type checker. Or, more general,
it’s about monitoring-functions.)
I wanted to do this with a nice and clean implementation, with
the real magic pushed down to a place I would never come again
(write once, read never). I wanted something like this (focus
on line 8):
1 class Foo 2 def bar(x, y, z) 3 # x should be Numeric 4 # y should be a String 5 # z should respond to :to_s 6 end 7 8 check_types :bar, Numeric, String, :to_s 9 end
(Focus on line 8, once again. Make it three times. It’s all
about line 8.)
That was good enough for him. “But you can’t do this. You
simply can’t. That’s magic.” I laughed at him, turned around
and did it…
That’s where this story is all about. To be more accurate: It’s
about how I did it, about monitor-functions and
method-wrapping, not about type-checking.