CONCEPT
closures example
DESCRIPTION
This document contains small examples of the usage of
(lambda-)closures. For technical details see the closures(LPC)
doc. For hints when to use which type of closure, see the end
of this doc.
Many Muds use 'details' to add more flavour. 'Details' are
items which can be looked at, but are not implemented as own
objects, but instead simulated by the environment.
Lets assume that the function
AddDetail(string keyword, string|closure desc)
adds the detail 'keyword' to the room, which, when look at,
returns the string 'desc' resp. the result of the execution of
closure 'desc' as the detail description to the player.
Now imagine that one wants to equip a room with magic runes,
which read as 'Hello <playername>!\n" when looked at.
Obviously
AddDetail("runes", sprintf( "Hello %s!\n"
, this_player()->QueryName()));
is not sufficient, as the 'this_player()' is executed to early
and just once: for the player loading the room.
The solution is to use closures. First, the solution using
lfun-closures:
private string _detail_runes () {
return sprintf("Hello %s!\n", this_player()->QueryName());
}
...
AddDetail("runes", #'_detail_runes);
or with an inline closure:
AddDetail("runes"
, (: sprintf("Hello %s!\n", this_player()->QueryName()) :)
);
Simple? Here is the same code, this time as lambda-closure:
AddDetail( "runes"
, lambda(0
, ({#'sprintf, "Hello %s!\n"
, ({#'call_other, ({#'this_player})
, "QueryName" })
})
));
Why the extra ({ }) around '#'this_player'? #'this_player
alone is just a symbol, symbolizing the efun this_player(),
but call_other() needs an object as first argument. Therefore,
the #'this_player has to be interpreted as function to
evaluate, which is enforced by enclosing it in ({ }). The same
reason also dictates the enclosing of the whole #'call_other
expression into ({ }).
Note also the missing #'return: it is not needed. The result
of a lambda-closure is the last value computed.
Another example: Task is to reduce the HP of every living in a
room by 10, unless the result would be negative.
Selecting all livings in a room is simply
filter(all_inventory(room), #'living)
The tricky part is to reduce the HP. Again, first the
lfun-closure solution:
private _reduce_hp (object liv) {
int hp;
hp = liv->QueryHP();
if (hp > 10)
liv->SetHP(hp-10);
}
...
map( filter(all_inventory(room), #'living)
, #'_reduce_hp)
or as an inline closure:
map( filter(all_inventory(room), #'living)
, (: int hp;
hp = liv->QueryHP();
if (hp > 10)
liv->SetHP(hp - 10);
:) );
Both filter() and map() pass the actual array item
being filtered/mapped as first argument to the closure.
Now, the lambda-closure solution:
map( filter(all_inventory(room), #'living)
, lambda( ({ 'liv })
, ({#', , ({#'=, 'hp, ({#'call_other, 'liv, "QueryHP" }) })
, ({#'?, ({#'>, 'hp, 10 })
, ({#'call_other, 'liv, "SetHP"
, ({#'-, 'hp, 10 })
})
})
})
) // of lambda()
);
It is worthy to point out how local variables like 'hp' are
declared in a lambda-closure: not at all. They are just used
by writing their symbol 'hp . Same applies to the closures
parameter 'liv .
The lambda-closure solution is not recommended for three
reasons: it is complicated, does not use the powers of
lambda(), and the lambda() is recompiled every time this
statement is executed!
So far, lambda-closures seem to be just complicated, and in
fact: they are. Their powers lie elsewhere.
Imagine a computation, like for skill resolution, which
involves two object properties multiplied with factors and
then added.
The straightforward solution would be a function like:
int Compute (object obj, string stat1, int factor1
, string stat2, int factor2)
{
return call_other(obj, "Query"+stat1) * factor1
+ call_other(obj, "Query"+stat2) * factor2;
}
Each call to Compute() involves several operations (computing
the function names and resolving the call_other()s) which in
fact need to be done just once. Using lambda-closures, one can
construct and compile a piece of code which behaves like a
Compute() tailored for a specific stat/factor combination:
closure ConstructCompute (object obj, string stat1, int factor1
, string stat2, int factor2)
{
mixed code;
// Construct the first multiplication.
// The symbol_function() creates a symbol for the
// lfun 'Query<stat1>', speeding up later calls.
// Note again the extra ({ }) around the created symbol.
code = ({#'*, ({ symbol_function("Query"+stat1, obj) })
, factor1 });
// Construct the second multiplication, and the addition
// of both terms.
code = ({#'+, code
, ({#'*, ({ symbol_function("Query"+stat2, obj) })
, factor2 })
});
// Compile the code and return the generated closure.
return lambda(0, code);
}
Once the closure is compiled,
str_dex_fun = ConstructCompute(obj, "Str", 10, "Dex", 90);
it can be used with a simple 'funcall(str_dex_fun)'.
DESCRIPTION -- When to use which closure?
First, a closure is only then useful if it needn't to live any
longer than the object defining it. Reason: when the defining
object gets destructed, the closure will vanish, too.
Efun-, lfun- and inline closures should be used where useful, as they
mostly do the job and are easy to read. The disadvantage of lfun- and
inline closures is that they make a replace_program() impossible
- but since such objects tend to not being replaceable at all, this is
no real loss.
Lambda closures are needed if the actions of the closure are
heavily depending on some data available only at runtime, like
the actual inventory of a certain player.
If you use lfun-closures and find yourself shoving around
runtime data in arguments or (gasp!) global variables, it is
time to think about using a lambda-closure, compiling the
value hard into it.
The disadvantages of lambda closures are clear: they are damn
hard to read, and each lambda() statement requires extra time to
compile the closure.
SEE ALSO
closures(LPC), closure_guide(LPC), closures-abstract(LPC)
|
