Re: adding date/time calculations to glib

["Daniel Solaz" <dsolaz sistelcom com>]

Havoc Pennington wrote:
>Other languages also have libraries providing linked lists, hashing, and
>everything else in glib. It is inherently redundant with all non-C
>languages. Date functions would not be redundant with any common C
>library though.
Of course they do, and I certainly don't use glib's lists and hashtables
when I have native alternatives, but these data structures seem to be
absolutely necessary for some important widgets to work, while date/time
functions are not. If someone managed to make gtk widgets use equivalent
non-C data structures then I would automatically stop using (and
downloading) glib. If C lacks everything (I know, I'm a C
sort-of-professional programmer), then give extra libs to C people, but
do not force everyone to have them.
>As far as I know glib is supposed to be a general purpose library which
>fills in some gaps in the C language. If you don't use functionality X,
>Unix will leave it on disk. It doesn't bother you.  (Not that date
>functionality would be big - 10K? 20K?) And this stuff is in Gtk anyway,
>look at the top of gtkcalendar.c. It's just being cleaned up and moved.
So glib will grow without limit...
Ok, then, develop generic libraries that address these needs and serve
for more than just supporting gtk widgets. They'll be welcome, trust me.
Containers and dates seem to me different enough to live in different
libs.
Anyway, I'll still have to download it all, *my* modem will not leave
functionality X on the server (maybe I just need a newer, smarter one).
Ok it's only 10/20k, but if we get into this practise we'll soon have to
download plenty of software for something that is supposed to be 'small
and efficient' (sorry I believe that less and less).
The Qt guys also rolled their own string and containers classes. I
think they're now considering adopting the STL. Too bad there's no STL
for C, maybe it's time someone writes it. But not as part of gtk.
>It would be convenient for programmers and for people who avoid
>downloading and compiling yet another library. Assuming it's good,
>general-purpose functionality, I see no reason to give that up just to
>save a few K on a 1 gig disk.
3 gig, actually, mostly empty space.
I see no reason to give up at all. You just said C people need it. All I
say is don't put it all together.
Sorry if it looks like I'm ranting (am I?). It's just that, since people
insist on coding in C, I'd like C to have a decent standard library so
that people don't have to implement date/time functionality several
times for several different projects. Specially if these several
implementations will end up in my hard disk.
Please flame me directly. This already is off-topic.
-Daniel, who, according to the boss, may soon have to roll his very own
RDBM in ANSI C. Go figure.