Re: [gnome-db] Minor API change and MySQL [update/delete]_row



> >   1) no const object as the first argument
> > 
> >   2) return const if value shouldn't be edited
> > 
> >   3) don't force users to cast of const

> I think 3) is the problem, and that's why we are talking about it. Then,
> if we look at the other libraries we are using ourselves (glib, for
> instance), we see that that problem does not exist, since const is only
> used in a very few places.

If you really want (1), then (2) is the one to let go.  A guideline
like (1) implicitly implies that we don't return const object.  Do you
see any glib, gnome, or any good library that return const object, but
expect to take that object back in non-const?


> yes, I know, but a more important objective is to make the API really
> easy to learn for people who know similar APIs. That is the case for
> GNOME libraries,

(3) doesn't break familiarity.  The user's code stay exactly the same
whether we take const in a function or not.  (2) breaks familiarity.
The user have to declare a pointer to const object and/or cast off
const at some point.  They don't have to do that in other G/Gtk/Gnome
libraries


> I am more and more in favour of not returning const from the
> functions, and make the documentation clearly state not to free that
> returned value.

What you says here is we stay with (3) and break (2).  I'm fine with
this.  (3) is more important than (1) and (2), and our current API is
breaking it.  As long as we fix (3), I'm happy.



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