Just to present the other side of the argument...
Scott Michel wrote:
>
> > > If we start using glib queues, I think we should remove qop.h
> > > completely, and use it all over. BTW, I was unable to find the glib
> > > queue operation in my v1.1.5. Which version has them?
> >
> > i found it in version 1.3
> >
> > the glib queues are a bit faster than our queues, since they maintain two
> > pointers (head and tail), and you can pop from either.
>
> I seriously vote against YAL (yet another library.) I don't have
> anything against glib, per se, but it's yet another library to
> make sure we have installed **correctly**, a concept that seems to
> kill even the most experience of us from time to time.
FWIW, I seriously vote in *favor* of using any library that provides
features useful to the project. There are a number of reasons...
* I don't want to have code to do queueing in 500 places on my machine
because every program re-wrote it. Quite apart from being a waste of
space and (more importantly?) download time, it means 499 more places
where bugs can creep in. If each project duplicates the code from one
source, it's no better, because then every program has to be upgraded
each time a bug is found in the library's code. It's bad enough that
current politics require me to have 3 or more windowing toolkits and two
sets of desktop environment libraries if I'm going to run all
programs...
* If you use a distribution with a package manager, library dependencies
can be managed automatically. I don't know about rpm, but debian makes
the dependency completely invisible; if I ask for japhar, it would
automatically install glib first. If rpm doesn't do this, it would be
easy to provide a copy of the glib rpm with japhar (since glib is free
software, of course). If you choose to use a distribution without a
package manager, or to install japhar when it hasn't been packaged (ie
when still under development), you should expect to have to do a bit of
extra work. Design decisions shouldn't be based on this minority.
If these reasons aren't enough by themselves, then bear in mind that if
japhar is to be used with the AWT from classpath (which probably will be
true most of the time, eventually), GTK is required anyway, since
classpath's peers are GTK based. GTK requires glib, right?
At any rate, make whatever decision you feel is right - I just wanted
both sides of the story to get heard.
Just my .4 nickels,
Stuart.
