Re: 04: glib: g_list_free_1 should return ->next

[Guido Draheim <guidod-2003- gmx de>]

Owen Taylor wrote:
> Guido Draheim <guidod-2003- gmx de> writes:
>
>
> > Owen Taylor wrote:
> >
> > > If you want to make feature enhancment requests, the best procedure
> > > is:
> > > - File them in bugzilla
> > > - (optional) send mail to gtk-devel-list if you think
> > >   that discussion on the issue would be good.
> >
> > the gtk.org docs say that feature requests shall be
> > sent to gtk-list gnome org, and so I did. 
>
>
> Which docs? File a bug about them... ;-)
>
> That would have been accurate 4 years ago or so, but isn't
> any more. The GLib README includes up to date information, as 
> does the GTK+ FAQ.       

http://www.gtk.org/mailinglists.html

" <gtk-devel-list gnome org>
   This list is for developers of GTK+ to discuss code. General GTK+
   questions should not be asked on this list, as that is more appropriate
   for gtk-list. Requests for new features should not be sent to this list,
   as that is also more appropriate for gtk-list. "

the glib tarball's README does not tell about code review or
something close to "enhancement" discussions ;-)= ... hmmm,
gtk faq (just looking at it now...), I can't say that any of
section 3 does match either...

btw, I didn't knew that bug reports are noticed/discussed
better than entries in a mailinglist? That sounds dubious
to me, ye know...

> > The items
> > that I am going post are actually the result of a
> > code review and experiences with glib, I am not sure
> > if there is a need to file them just to have them
> > seen closed immediatly.
>
>
> It's no harder to file a bug than to send a mail. And
> if you send the mail, especially to gtk-list, there is
> a good chance that we'll simply not see it or forget about it.
> Which isn't a good use of your time, I don't think.

again, as above, is that a place to discuss features and
their way they are now and why not different? hmmm....
what about gtk-devel list?

>  
>
> > > I don't think this change makes sense though:
> > > A) g_list_free_1() doesn't unlink the list node either,
> > >    so just returning next doesn't do any good.     g_list_free_1()
> > > simply frees a single list node
> > >    that is already unlinked.
> > > B) g_list_delete_link is exactly what you are looking for.
> >
> > in other words,
> > list = g_list_delete_link (list, list);
> >
> > looking through the fifteen places where g_list_free_1 is
> > currently used, that would be also true about there - so that
> > the free_1 would have to be depracated. It is not done since
> > it is known about there that we are the head and no unlink
> > operation is actually needed since it is intended to just
> > walk-and-free the list. It is actually a common task to do,
> > to have a "select" routine to return an allocated glist and
> > have the receiver walk-and-free the result-set.
>
>
> g_list_free_1 is a perfectly legitimate operation, it't
> just not what you are looking for. It's basically the
> opposite of g_list_alloc().
>
> The reason we added g_list_delete_link() (a GLib-2.0 addition)
> was because the operation of deleting the head node off of 
> a list was a common one. The code you are looking at was
> probably written before then.

aaaaahhh!!!!!

however, some of these places are in glib2 itself - and given
the lack of programming examples, they are taken as a guideline.

furthermore, the g_list_delete_link algorithm is a bit bloated
for the operation of g_list_delete_head - the case that checks
for (list == link) is a bit late (in this case, the releveant
code point is in _g_list_remove_link).

>  
>
> > The 04 notification
>
>
> What is an O4 notification?

there are 36 more items on my list *grin*

I'll feed them one at a time, so that people are not
scared off and unwilling to discuss the things since
they have better things to do than sit over a code
review... giving it a few minutes a day is much more
appropriate ;-)

> > shall simply tell you that there is room
> > for a better way of supporting this common operation. Otherwise,
> > just delete free_1 and see what your developers say.
>
>
> We make incompatible changes _very_ reluctantly, even between
> major versions where they would be possible.

sure, me too. However, it's not made "depracated" either,
while quite some other functionality is not marked as such
and I can not see quite why. So this free_1 function is
not to be replaced by delete_link for real, isn't it... ;-)

cheers, guido