Re: to GList or not to GList?

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> > However, in my opinion, it is a bad ideia to rely on
> > glib to supply your list needs, unless you are writting
> > a small app. The core of an application should not deppend 
> > of glib, which primary purpose is to support gtk needs.
> > If you change the GUI toolkit, the inner core, the engine 
> > of your program, should remain the same. Yes, this means
> > to have your own lists in the code, not those supplied
> > by the GUI toolkit.
>  But imho programmer should use Havoc's method ;-)
>  i.e. cut appropriate code from glib (i.e. list's code).
>  So we: (1) don't invent wheel
>         (2) get checked and tested code
>         (3) cut off navel-string: we can use that code
>             with any GUI, even if that GUI use another glib
>             version or doesn't use it at all.

The question here is about code control, not code origin.

I didn't say that people should write their own lists.
I am totally happy if programmers cut and paste checked and 
tested lists from glib or any other reliable source to their
own code (license permitting of course) as long as

this becomes a new instance of the code, totally
independent of its source, glib or wathever, so the
app inner core lists don't deppend of the original code 
at all.

the programmer fully understands the code delicacies
that she/he is introducing in her/his app inner core,
where bugs have widespread effects and are hard to find.

In short, I agree with your points (1), (2) and (3) :-)

Carlos