Method Binding

The first problem, in analyzing Ruby method binding, is finding all the method definitions and uses. As discussed in Parse Trees, there are tools to parse Ruby code, generate S-expressions, etc. This solves the first problem mentioned above, at least for the cases where the definitions and uses are static.

The second problem is figuring out (where possible) how to match up a given call with the method that responds to it. Although this matching is performed at run time, and depends on the type of the object involved, most method calls are predictable from the code base. Much of the remainder can be traced at execution time. And, worst case, we can always ask a human for help...

Predicting Behavior

If a method's receiver is a constant (eg, a class), we can predict which method will receive the message. In some other cases, we may be able to predict the type of the receiver through static analysis, though this involves Real Work (TM).

Dynamic Tracing

Although we probably won't need dynamic tracing in order to find most of the method calls and definitions, it may prove useful in situations where metaprogramming is being used. More generally, we will need to use it in cases where the type of the method's receiver cannot be determined from the code.

This wiki page is maintained by Rich Morin, an independent consultant specializing in software design, development, and documentation. Please feel free to email comments, inquiries, suggestions, etc!

This topic: Projects/Arti/Patterns > WebHome > Ruby_Method_Binding
Topic revision: 08 Jun 2008, RichMorin
This site is powered by Foswiki Copyright © by the contributing authors. All material on this wiki is the property of the contributing authors.
Foswiki version v2.1.6, Release Foswiki-2.1.6, Plugin API version 2.4
Ideas, requests, problems regarding CFCL Wiki? Send us email