Re: TODO for GLib 1.4

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> > I would disagree with this. Basically, it makes things more
> > complicated to get marginal gains in a few cases. I think we should
> > make things simpler for our users by paying attention to worst-case
> > performance. A frozen hash table has HORRIBLE worst-case performance.
> > 
> > If it made things 10 times faster, then, yes, I would say that it
> > would be worth it. But the speedups you have here seem to be order
> > 20%.
> 
> So you propose to remove the _free and _thaw functions alltogether. Thats fine
> with me. Should there still be the functions for compatibility or should I
> just remove them? 

Hmmm, I think for GLib 1.4 we should leave the functions there,
but make them do nothing, and mark them in the source and documentation
as deprecated.

We might want to create a glibcompat.h (like gtkcompat.h)
with stuff that can be disabled with -DG_DISABLE_COMPAT_H
 
> > > * Regarding Bug #5097. I would just change g_basename to return a
> > > string, that must be freed. This of course could open memory
> > > holes. So an alternative might be to rename the function to
> > > g_basename2() with the new semantics, remove the old one and rename
> > > the function back to g_basename in GLib 1.6, such that everyone
> > > using the function is aware of the change.  --> nothing.  *
> > 
> > Hmmmm, that would still break everybody's code in the 1.4 => 1.6
> > transition. 
> 
> Do you mean the 1.2=>1.6 transition here? Will such a transition happen? Based
> on current experience 1.6 will be out in 2 years. Who will change versions
> that late?

No, I mean, the 1.4 => 1.6 transition.

At that point, those people using g_basename2() will have to
convert their code to use g_basename().
 
> > I would say that the right way to fix this would be
> > to introduce, say:
> >
> >  g_path_get_basename()
> > 
> > that does the right thing, and deprecate g_basename. I'm just not sure
> > that this is enough of a problem to be worth trying to fix.
> 
> My proposal actually would be to break the semantics of the function and make
> a big warning into the transition file and the documentation and fix all
> occurences in cvs.gnome.org

I really don't like breaking the semantics of a function unless the
compiler catches it. I guess you mean to do this by removing
g_basename(), but if we do this, I'd rather use a pretty name that
we can leave in place, instead of something like g_basename2() that
we plan to change later.
  
> > > Regarding Bug #6707: I would just add these reserve functions for
> > > arrays.  --> add them.
> > 
> > This sounds reasonable. One possible concern is that for a
> > zero-terminated array, you get a double alloc then. Another option
> > would be to mimic g_string_sized_new() and have g_array_sized_new().
> 
> Yes, sounds better. If one really have to resize it later, he could actually
> do it like that:
> 
> len = array->len;
> if (len < reserve_size)
>   {
>     g_array_set_size (array, reserve_size);
>     g_array_set_size (array, len); /* or simpler: array->len = len */
>   }

This is ugly - but just don't think that deciding after creation that
an array needs to be reserved to some size _after it has been created_
is very common so I think having this as the only mechanism is
probably fine.

Regards,
                                        Owen