Re: glib: changes to the g*_array API.



Josh MacDonald wrote:
> 
> First, note that the order preservation only applies to the pointer
> array. 

Why is that ???

> And as to code breakage, I have a lot of code outside of the
> gnome CVS repository using the interface, and I'd rather not break it.

Ah, but it would at least not be a silent breakage.

> I intentionally made the interface the way it is.  It is most efficient,
> of course, to not preserve order.

Yes, of course.
 
> I think that the option to preserve order should not be implemented as
> a new argument.  Instead, I think there should be two functions so that
> the meaning is clear from reading each usage and to avoid breaking 
> existing code.  The option can further be added to the g_array class of
> functions as well, and there are currently no remove functions implemented
> for that class so there will be no breakage.

I did it this way first, but there has then been much code duplication and
so I thougt it would be good with an extra argument.
 
> Now that we've decided there should be two behaviors, and I hope we can
> agree on using two functions, the decision remains as to the default.  We
> can have
> 
>         g_ptr_array_remove_index_preserve
>         g_ptr_array_remove_index

I would prefer this. The 'shorter' function is the faster one. If somebody
is looking for a 'preserve order' function, he will certainly find it.
  
> I think that all three of the array classes should have an identical
> interface.  It is currently not this way because of the particular
> order in which code of mine got merged into the main glib line and
> in which people started using the interfaces (thereby preventing
> me from cleaning up older interfaces).  While we're at it, some time
> ago I changed all of the g_*array_truncate function to be named
> g_*array_set_size, and I'd like to change the name of g_string_truncate
> to be in line with the others.  Thoughts?  There are a few other nit-picks
> I have with the glib interface which are going to be difficult to change
> at this point, but still may be nice: the inconsistent usage of _free and
> _destroy is one of them, and I can't remember the others.

My opinion of course is: If you're sure about it, break it to make it
consistent. Look at dos/windows and their 'never break compatibility'
(which obviously isn't working on the other hand, see ms-word formats). In
open source this breakage isn't a problem, because everybody can download
the newest version of lib and prog and such get a working copy. But OTOH
I'm not in the position to give advise on that .... ;-)

Bye
Sebastian

(still waiting to see, why this doesn't apply to GArray)

-- 
+--------------============####################============--------------+
| Sebastian Wilhelmi, Institute for Computer Design and Fault Tolerance, |
| University of Karlsruhe;  Building 20.20, Room 263,  D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de;  fax: +49 721 370455;  fon: +49 721 6084353 |
+-----------------> http://goethe.ira.uka.de/~wilhelmi <-----------------+



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]