Thus, an expression can know if the context in which it's being
evaluated requires a string, and if so, determine it's output
accordingly. For example:
account ; returns the full name of the posting's account
account.total ; here the context is SCOPE, so account is an obj
Lots of symbol_scope_t throwaway objects get created during value
expression calculation, and 99% of them are never used. Therefore, the
std::map which each contains is now within an optional<> wrapper, so
that no constructor happens unless one is actually used.
The different namespaces are:
Function Value expression functions, which receive a "context"
Option Command-line options
Precommand Commands which are invoked before reading the journal
Command Commands which are invoked after reading the journal
Directive Directives that occur at column 0 in a data file
This greatly eases the ability for Python uses to add intercept hooks to
change how the basic Ledger module functions. An example of what should
be possible soon:
import ledger
def my_foo_handler(value):
print "--foo received:", value
ledger.add_handler(ledger.Option, "foo=", my_foo_handler)
These strings are now collected automagically in the file po/ledger.pot.
If you'd like to produce a translation, just run this command after
building Ledger:
msginit -l LOCALE -o LANG.po -i po/ledger.pot
Where LOCALE is a string like de or en_GB, and LANG is a short
descriptive word for your language.
Then send me this .po file so I can commit it to the Ledger sources
(alternatively, you could maintain the file in a fork on GitHub), and
setup the build script to format and install your new message catalog
during a "make install".
The purpose of this class is much like Emacs' (interactive) form: it
allows a value expression function to declare exactly how many
arguments, and of what type, it intends to receive. It then offers
type-safe access to theese arguments in a consistent manner.
An example value expression function definition in C++:
value_t fn_foo(call_scope_t& scope) {
// We expect a string, an integer, and an optional date
interactive_t args(scope, "sl&d");
std::cout << "String = " << args.get<string>(0)
<< "Integer = " << args.get<long>(1) << std::endl;
if (args.has(2)) // was a date provided?
std::cout << "Date = " << args.get<date_t>(2) << std::endl;
return NULL_VALUE;
}
There is also an in_context_t<T> template, which finds the context type
T in the current scope hierarchy. The in_context_t then also acts as a
smart pointer to reference this context object, in addition to serving
the same duty as interactive_t. This combination of intent is solely
for the sake of brevity.
value_t fn_bar(call_scope_t& scope) {
in_context_t<account_t> env(scope, "sl&d");
std::cout << "Account name = " << env->fullname()
<< "String arg = " << env.get<string>(0)
<< std::endl;
return NULL_VALUE;
}
As you can see here, 'env' acts as a smart pointer to the required
context, and an object to extract the typed arguments.
For example, "ledger eval options.limit" prints 0 (for false), but:
"ledger -l hello eval options.limit" print "hello"s, since the value of
options.limit, once set to a value, is that string. For flag options,
such as -Y, eval prints 0 if unset, and 1 if set.
This feature allows value expressions to be conditionalized based on the
presence of user options.
