Professional IronPython

Using IronPython Constructively
 
❘
 
305
The most common way to call a delegate of this sort is to create a rule that DLR can use to call 
it. Of course, you still have to know what to call. DLR supports a number of methods to perform 
this task, but the method that works with an 
ActionBinder
is to create an object that implements 
IDynamicObject
as described in the section “Working with IDynamicObject” earlier in this chapter.
To make rules work, your code has to include a 
GetRule()
method that returns a 
StandardRule
object. Inside 
GetRule()
is a switch that selects an action based on the kind of action that DLR 
requests, such as a call (
DynamicActionKind.Call
). When DLR makes this request, the code cre-
ates a 
StandardRule
object that contains an 
ActionBinder
. The 
ActionBinder
determines what 
kind of action the call performs. For example, you might decide that the 
ActionBinder
should be 
LanguageContext.Binder
, which defines a language context for the function. The language context
is a definition of the language’s properties, such as its name, identifier, version, and specialized fea-
tures. (You can learn more about how a language context works at 
http://www.dotnetguru 
.org/us/dlrus/DLR2.htm
.) The code then calls 
SetCallRule()
with the 
StandardRule
object,
the 
ActionBinder
, and a list of arguments for the function.
Now, here’s the important consideration for this section. The 
ActionBinder
is actually part of the 
language design. If you wanted to create a new language, then part of the design process is to design 
an 
ActionBinder
for it. The 
ActionBinder
performs an immense amount of work. For example, 
a call to 
ActionBinder.ConvertExpression()
provides conversion information about the data 
types that the language supports. Of course, IronPython already performs this task for you, but it’s 
important to know how things work under the hood in case you encounter problems.