"Bradley M. Kuhn" <[EMAIL PROTECTED]> writes:
> However, I wonder----could we mitigate the problems you describe by
> allowing users who don't want it to turn off the option at compile
> time, and by being careful to control what access is given to the
> scripting language?
>
> Baring that, if a scripting language is not a first-class-citizen,
> what can one expect *not* to be able to do in that scripting
> language?
Really the main restriction is that you have to write anything that
you want to be available to all users in a standard GnuCash
implementation in guile.
In fact my tendency is to think of the code like this:
1) Anything in the engine must be written in C.
2) Anything deals directly with GNOME/Gtk should, at least right
now, be written in C.
3) Anything else I write in scheme unless I have a good reason not
to (i.e. issues of performance, complexity of the C level
interface, or my mood). Especially things that the user might
want to mess with, "(gnc:set-enforce-double-entry #t)", should be
done in scheme.
As a practical matter, none of the other languages have nearly as
solid an interface to the C level as guile. The SWIG perl interface
is unmaintained, and had some serious problems. The idea of
automatically processing the headers to get the information, unless
you're actually going to modify gcc to do the job right during a
normal pass, is IMO a bad idea.
On the scheme side I've gotten g-wrap to mostly do the right thing,
and it's going to get better.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
