Re: A couple of GQueue additions

[Tim Janik <timj gtk org>]

On 5 Jun 2000, Owen Taylor wrote:

> 
> Would anybody mind if I added:
> 
>  void g_queue_remove      (GQueue *queue, gconstpointer data);
>  void g_queue_remove_link (GQueue *queue, GList *link);
>  void g_queue_delete_link (GQueue *queue, GList *link);
> 
> The reason for these additions is that to implement these requires
> not only reading GQueues's internals, but also modifying them.
> 
> Yes - these additions go beyond a (de)queue, but they are going
> to be used fairly frequently in many uses of a GQueue.
> 
> g_queue_remove and g_queue_delete_link can be pretty trivially
> implemented in terms of g_queue_remove_link, but I'd like to
> have them there for parallelism to GList and GSList.

i see your point. the thing is, how close do we want gqueue to
follow the GList/GSList APIs?
last time we discussed this, we decided to be as restrictive as possible
and provide pure "Queue" functionality only. since we expose the queue
structure internals in the header file (as is usual policy in glib/gtk+),
we shouldn't wrap pure accessor convenience functions (e.g. g_list_find()),
but if we add g_queue_remove/g_queue_*_link, sooner or later we'll have to
face the argument of adding g_queue_sort() and similar functions that require
updating of GQueue internals. so before you go ahead and implement the above
functions, i want to see us agree on of the two policies:

1) GQueue should only implement pure Queue functionality (which leaves us
   where we are currently)
2) GQueue should mirror the GList API in terms of all mutators

something inbetween will fuel religious discussions and make dicisions on
our side about having a requested g_queue_* variant or not seem pretty
arbitrary, so i rule that out right now ;)

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ