otaylor at redhat.com
Mon Jul 21 17:24:27 EEST 2003
I really don't think this debate is going anywhere productive;
I'll make a few observations and suggest we let the topic
lie for now; there is a lot of progress to be made with
less controversial issues.
- Clearly some people have (perhaps irrational) objections to
GLib; we've accomodated that in the past, we'll have to
continue doing that for libraries we want to have the
widest possible acceptance.
On the other hand, if people writing a facility think they
can make their facility more compelling by using GLib
instead of reinventing the wheel, they should be free
to balance that against the downsides of discouraging
Using GLib in a library certainly shouldn't be considered
*worse* than making your library 400k bigger by any other means.
(Like including your own copies of the Unicode tables,
which are a good fraction of GLib's size)
- There *are* certainly legitimate reasons to avoid GLib
for some tasks. One of the primary ones is that (like
Qt) it doesn't generally allow for recovery from
out of memory conditions.
- Making GLib part of the "freedesktop.org distribution",
is a separate issue from using it in freedesktop.org
distributed libraries. GLib is currently used in
some utilities hosted on gnome.org, and can indeed
make writing such a utility much easier.
While I'll stay neutral on the issue of using GLib
in libraries, I will say that I think having GLib
as part of the freedesktop.org distribution, perhaps
"by reference" (like freetype, libpng, etc) would
be a neat thing.
But that's really up to the release team to decide.
- When building APIs, the GLib data structures aren't particularly
useful; there is no reason to stick a GList into a prototype
in most cases.
What *is* actually extremely useful is the abstractions in
GObject; having standard memory management places, ways
to attach external data, ways of doing callbacks, etc,
is a huge win, particularly because it makes connecting
a library to language bindings much easier.
It's actually much easier to connect a library using GObject
to C++ than an library that rolls everything by hand.
This, and the Unicode tables, are the primary reasons
that Pango uses GObject.
But I doubt I'd manage to convince anybody who has't
actually had a fair amount of experience with GObject
[ To make the disclosure obvious, I'm one of the maintainers
of GLIb ]
More information about the xdg