Re: Getting libgnome* into shape

[Bastien Nocera <hadess hadess net>]

Michael Meeks wrote:
> Hi Havoc,
>
>         It's been a while and I didn't respond to this at all - but
> perhaps it's interesting to do so:
>
> On 29 Aug 2001, Havoc Pennington wrote:
>
> > I've seen this repeated several times - I would like to point out
> > that if you have a string that you parse, it still constitutes an
> > API.
>
>         Of course - the real question is: is it a better API ? and
> what are the alternatives.
>
>
> > Let's use a popular #gnome joke as an example. Say I have the
> > function strcmp():
> >
> > int strcmp (const char *a, const char *b);
> >
> > So I change this to a moniker:
> >
> > "libc:strcmp:string1=foo,string2=bar"
> >
> > I do not now have less API. I now have an untypesafe ad-hoc
> > scripting language.
>
> 	True, there is no less API - but there are a few plusses:
>
>         * Type Safety:
>
>                 I think any loss in type safety here is traded vs.
>         convenience; ie. you can do:
>
>                 "libc:strcmp:string1=123,string2="
>
>                 And instead of a segfault on a NULL string2 pointer
> 	you are protected, and 123 is mapped to a
> 	string. Alternatively if you don't like automatic type
> 	coercion, you could specify needing strings to have ''
> 	delimitation, and then return a warning.
>
>                 As for type safety - so much of our code is
> 	horrendously type unsafe - signal emmision, closures
> 	etc. etc. and much of our type checking is done at run time
> 	anyway.
>
>         * Expandability
>
> 	Data based APIs such as the above are expandable; eg.
>
>                 "libc:strcmp:string1='foo',string2='baa',insensitive=1,
>                  collate=1"

Bad example again ;) We have g_strcmp which is safer than the libc 
equivalent strcmp... Just picking on you on that.

<snip>


Cheers