Re: Proposal for a collection API in glib

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2008-07-17 at 14:22 -0400, Jamie McCracken wrote:
> On Thu, 2008-07-17 at 13:37 -0400, Havoc Pennington wrote:

> As philip's proposal centres around easier bindings this would only
> affect public API dealing with licts/collections so all of the above
> will probably have negligible impact. 

Exactly (I agree).

> GList would still be around for internal usage or where performance
> matters. The onus would still be on devs to make their api more binding
> friendly by using iterators so I feel its important for them to have
> that choice

GList for performance?! :-)

Not for the things the vast majority of GLib based library developers
are using it for! And if GList must be used in a high performance
situation, the kernel's list.h is better designed anyway: the item's
data is in the same allocation as the next/prev ptrs, instead of having
an allocation for the data and another allocation for the list node.

Looking at how GList is used all over our project's code nearly always
makes me conclude that most people who used a GList probably wanted a
GPtrArray instead. Its realloc overhead is usually not expensive at all.

There are specific uses for doubly linked lists, of course. For UI rich
applications (where you usually want things like sorting and index based
accessing your collections) I don't think GList is very useful.

For index-based access and sorting it's even a performance 'mistake'.

The problem is, I think, that GList's API is more easy than GPTrArray's.

Which validates my POV that:

  - The simple, most common use cases, must be easy
  - The complex things must (just) be possible

If a complex thing becomes even more complex caused by wanting to make a
common use case even a little bit more simple, then don't even think
about it and DO make the complex thing even more complex .. indeed.

Just make a wiki page on Live explaining how to do the complex thing.
The developers who feel brave (and have some competence) will figure it
out anyway.

But don't bother app developers, who spend 90% of their time codifying
common use cases, with complexities.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be