Re: GList and GSList data abstraction

[Tim Janik <timj gtk org>]

On Wed, 1 Mar 2000, Kevin Lai wrote:

> I also agree that allowing an error like that is a bad idea. The other 
> abstraction macros also allowed it, so I changed them in the included 
> updated patch too.

> -#define g_list_previous(list)  ((list) ? (((GList *)(list))->prev) : NULL)
> -#define g_list_next(list)      ((list) ? (((GList *)(list))->next) : NULL)
> +#define g_list_previous(list)  (list)->prev
> +#define g_list_next(list)      (list)->next
> +#define g_list_data(list)      (list)->data

your versions of g_list_previous() and g_list_next() are plain broken,
because NULL is actually a valid list (an empty one), and as such has
a successor and a predecessor (both empty as well).

as havoc said, g_list_data() would make *some* sense, but in effect,
the macro provides no real benefit, other than pur "abstraction".

since we are still talking plain C here, and there are a bunch of other
structures in glib.h for which we'd have to implement per-field
accessors as well to be consistent, and since everyone uses list->data
already anyways, i don't see the point in providing these macros.
(you're of course still free to have these macros in your own code
if you insist on that abstraction level).

> Any thoughts on removing (or at least deprecating) redundant functions 
> like g_list_nth_data(), g_list_free_1(), g_list_remove(), and 
> g_list_delete_link()?

i don't see how these functions are redundant, none of them could
be replaced by another without additional code.
i'd rather point out your macros as redundant, i.e. g_list_data() can
be replaced (other than by the obvious list->data which breaks abstraction)
by g_list_nth_data (list, 0), keeping the abstraction.

---
ciaoTJ