On Tue, Jan 08, 2002 at 01:36:37AM +0100, Felix von Leitner wrote:

> If you want to write a successful library, don't provide a million cool
> functions that cover every case but almost noone ever needs. Provide a
> few functions that are obvious, i.e. you only need to look at the
> prototype to see what it does.

Some excerpts from glib.h:

GString* g_string_new (const gchar *init);
void g_string_free (GString *string,
                             gint free_segment);
GString* g_string_append (GString *string,
                             const gchar *val);
GString* g_string_prepend (GString *string,
                             const gchar *val);
GString* g_string_insert (GString *string,
                             gint pos,
                             const gchar *val);
void g_string_sprintf (GString *string,
                             const gchar *format,
                             ...) G_GNUC_PRINTF (2, 3);

These all seem quite clear from their prototypes except for g_string_free; I
had to look up what free_segment was for (and it's still not clear).

> No, wait. That can be put even stronger. They want tools they don't
> need to keep _state_ to understand! I don't want to remember
> interfaces. Remembering interfaces takes brain real estate that I can
> use better to remember Aunt Annie's birthday. I want interfaces that
> are obvious. Interfaces that I don't have to remember because they are
> so obvious. One look at the header file and everything is clear.

I agree. It shouldn't matter if you forget the interface; you should be
able to reconstruct the necessary brain data structures by looking at the
prototype (or better, they should be exactly what you expect them to be).

> glib is everything but nice. The autoconf stuff is completely broken [1],
> glib is huge, obscure and opaque. Programmers use it not because it
> looks good but because group pressure forced them to.
> [...]
> [1] try to cross-compile glib to see what I mean. Using autoconf is bad
> enough if you set out to write obvious code. But glib tries to find out
> the size of the different integral types (huh? what for?), and provides
> its own not cross-compiler capable check, although autoconf comes with a
> perfectly well-documented cross-compiler capable check already! I wrote
> several mails, even sent in a patch, but nobody cares to fix this. glib
> needs to be taken behind the barn and shot. There is a lot more horse
> manure in that code than I want to get into here. They need the integer
> sizes for their "let's store a pointer list in an integer array"
> function (WTF? Don't ask me why that is needed. "Legacy reasons", I'm
> told).

I wouldn't consider something that doesn't cross-compile to be "completely
broken"; that is something of a corner case. As for having its own
cross-compiler check, I just looked in the source for glib 1.2.10-3, and I
see no such check in the distribution. The only references to cross
compilation are in macros distributed with autoconf.

The type sizes are necessary in order to provide fixed-size data types
(gint8, gint16, gint32, etc.). These are a godsend when porting to a
pre-C99 (or broken) system, which won't have <inttypes.h>. It also
determines byte order, which is annoyingly difficult to do portably.

As for storing pointers in integer types, that, unfortunately, is C for you.
That kind of code is everywhere, no matter how broken it is.

-- 
 - mdz

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]