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

[Owen Taylor <otaylor redhat com>]

Guido Draheim <guidod-2003- gmx de> writes:

> 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. "

Hmmm... that's not really right. I suspect that was added
to discourage questions of the form:

   I can't figure out how to create a pie chart with GTK+.
   Shouldn't GTK+ have a function call gtk_pie_chart_new()?

It may have also been written when I had more time to
read gtk-list... I've rewritten the list description to be:

  This list is for discusison of the development of GTK+ and GLib themselves.
  Questions about how to program in GTK+ should be asked on
  gtk-app-devel-list instead. Bug reports should generally be
  filed in bugzilla rather than sent here, though discussion of 
  the details of fixing particular bugs is appropriate.

> 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...

Basically, the difference is that bug reports _force_ 
us to act upon them (even it's a question of WONTFIX)
while if we read a mailing list post, we may think it's
a cool idea, but most likely won't remember it at all
when it comes time to work on features for the next
release.

Also, bug reports have lots more features that we find
useful:

 - Assigning categories/milestones/priorities/KEYWORDS
 - Sorting
 - Querying
 - Marking as resolved

etc. It's how we track open work items, and it's
easiest and most reliable if people file their own
bug reports rather than hoping that we will do it for
them.

> >>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?

Well, if you actually have questions or suggestions that you'd like
people to talk about, you should send them to the mailing list.

But if you want them acted upon, file them in bugzilla.
I often will mail the mailing list, and then file a bug
in bugzilla with a link to the mailing list post.

E.g.:

 http://bugzilla.gnome.org/show_bug.cgi?id=101959

> >>>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).

Better a tiny bit of code bloat than API bloat. I can't see
having separate delete_link() and delete_head() with the
difference of delete_head() being that it only works for the
head of the list.
 
> >
> >>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 ;-)
 
36... wow. please do file them in bugzilla instead/as well
as sending them to gtk-devel-list. It's just not manageable
to keep track of huge numbers of items without the sort
of database features that bugzilla provides.

> >> 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... ;-)

I don't really quite follow ... g_list_free_1() can be
used in places where delete_link() can't, since it makes
no assumptions as to how the node is linked.

Regard,s
                                        Owen