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

[Aaron Digulla <digulla wi-pc44 fh-konstanz de>]

Quoting Sebastian Wilhelmi (wilhelmi@ira.uka.de):

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

NO ! When I was browsing through the list of functions, I saw this function
and I never got the idea that it might distort the order of the elements in
the array ! So even if the docs of the function explicitly state this, it
is more natural to assume that "remove_index" just does what the function
says: It removes an item. The name of the function gives no hint that it
might do some kind of shuffling. Therefore you should make
"g_ptr_array_remove_index" keep the order and add
"g_ptr_array_remove_index_quick" which doesn't. This will avoid lots of
what-the-heck-is-going-on-my-code-looks-right errors and it will not break
compatibility (it unlikely that any code out there relies on the fact that
the function changes the order and very likely that all code will continue
to work if the order is preserved). When you want that additional speed,
then you can simply search'n'replace g_ptr_array_remove_index in your code
if you know that your code doesn't rely on the order of elements in the
array.

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

Well, you shouldn't break compatibility if you don't have to. But you also
shouldn't keep it if the ratio between costs and benefits is too high. In
this current issue, we're not breaking compatibility - the interface
doesn't change if we just change the behaviour (ie.
g_ptr_array_remove_index preserves order now), so the costs are minimal (no
code change, moderate speed loss, easy to fix for author of software)
compared to the benfits (unknown number of developers spending unknown hour
searching for a memory bug).

--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla     Assistent im BIKS Labor, FB WI
"(to) optimize: Make a program faster by      FH Konstanz, Brauneggerstr. 55
improving the algorithms rather than by       Tel:+49-7531-206-514
buying a faster machine."                     EMail: digulla@fh-konstanz.de