Re: Getting libgnome* into shape

[Michael Meeks <michael ximian com>]

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"

                Now of course - there are documentation issues here,
	and as you point out - any type checking is a run-time thing;
	but that's not frightening.

        * Simplicity

                In this case we convert a simple C call to a more
	complex call, however in many cases it is possible to reduce
	complexity by having a simpler representation - obviously,
	otherwise scripting languages would be junked in favour of
	raw C.

> Clearly the joke is a bit overblown. But just because you support
> 2000 features using the same single C function or CORBA method, it
> does not mean you somehow have less API.

        True - but the thing is; that with monikers - you are
instantiating objects outside the limited scope of your rigid C
linkage.  It is just not possible to use C linkage to manipulate and
especialy activate arbitarily complex components.

> So let's take this to the actual situation, instead of the
> ridiculous joke example.

        :-) I appreciated the joke - I just wanted to more fully
expound the merits of a data based API - since some people might be
put off using them just by reading the first part of this.

> Strings have the advantage over C that they can be more convenient
> and/or expressive, i.e. if I need to allow a complex specification
> it may be easier to do this:
>
>  gtk_label_set_text (label, "<span font='foo'>This is "
>                             "<b>bold</b></span>")

        Yes clearly :-) the single generic approach is more powerful
and beautiful.

> </random aside>

        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot