Christopher Browne <[EMAIL PROTECTED]> writes:
> I was reviewing the contents of /usr/include/glib.h over the
> holidays to see what interesting data structure abstractions GLIB
> (which underlies GTK) provides.
Now that glib is independent of gtk and gnome, then relying on its
features when they're appropriate might be a good idea. We wouldn't
even have to address the dependency on a particular GUI issue...
> c) macros for error handling (possibly less powerful than nana, but
> if it's ubiquitous, that may still win the day...)
I'm not sure they're any worse than nana. However, if we're going to
do anything about the error handling, I think we should try to figure
out what our goals and policies are and then figure out how to
implement them. We should do this in consideration of both the scheme
and C sides.
Both the GnuCash engine and GTK (which is based on glib) are
essentially OO systems written in C. (Objective-C was also an OO in C
approach, though it required some (minor?) compiler support. From
what I've seen, though I don't know it well, Objective-C looked
superior to C++ in a number of ways). I know others swear by it, but
personally, I'm glad that for GnuCash and GTK, C++ is nowhere to be
seen. After a number of years experience, I have a fairly substantial
set of axes to grind with C++. Its safer typing and a few other
things are fine, but much of the rest I think I can probably do
without.
Among other things, I've found that if you build a large project that
uses g++, C++, threads, STL, and optimization heavily, you'll see what
bloated compilation times really look like...
Sorry to wander off topic...
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
