You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2006/04/01 04:56:31 UTC
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
When did we drift back to this naming convention?
I thought we were trying to move twords lib_object_subobject_verb?
E.g. apr_dbd_name_get?
It's really aggrivating to use an api that's pulling in both directions
at once :(
Bill
niq@apache.org wrote:
> Author: niq
> Date: Fri Mar 31 16:28:12 2006
> New Revision: 390549
>
> URL: http://svn.apache.org/viewcvs?rev=390549&view=rev
> Log:
> Commit the b**** API for get_name, dammit!
>
> Modified:
> apr/apr-util/trunk/include/apr_dbd.h
>
> Modified: apr/apr-util/trunk/include/apr_dbd.h
> URL: http://svn.apache.org/viewcvs/apr/apr-util/trunk/include/apr_dbd.h?rev=390549&r1=390548&r2=390549&view=diff
> ==============================================================================
> --- apr/apr-util/trunk/include/apr_dbd.h (original)
> +++ apr/apr-util/trunk/include/apr_dbd.h Fri Mar 31 16:28:12 2006
> @@ -223,6 +223,17 @@
> APU_DECLARE(const char*) apr_dbd_get_entry(const apr_dbd_driver_t *driver,
> apr_dbd_row_t *row, int col);
>
> +/** apr_dbd_get_name: get an entry name from a result set
> + *
> + * @param driver - the driver
> + * @param res - result set pointer
> + * @param col - entry number
> + * @return name of the entry, or NULL if col is out of bounds.
> + */
> +APU_DECLARE(const char*) apr_dbd_get_name(const apr_dbd_driver_t *driver,
> + apr_dbd_results_t *res, int col);
> +
> +
> /** apr_dbd_error: get current error message (if any)
> *
> * @param driver - the driver
>
>
>
> .
>
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting "William A. Rowe, Jr." <wr...@rowe-clan.net>:
> Right - I wasn't being critical of your specific new fn, but just a general
> observation. In the past, we created renames_proposed to collect a list for
> review and comment before committing the changes; if you agree with the
> syntax _get _set etc, then let's start that list again.
apr_dbd_get_driver -> apr_dbd_driver_get
apr_dbd_check_conn -> apr_dbd_conn_check
apr_dbd_set_dbname -> apr_dbd_dbname_set
apr_dbd_get_row -> apr_dbd_row_get
apr_dbd_get_entry -> apr_dbd_entry_get
apr_dbd_get_name -> apr_dbd_name_get
I picked this list up from here (hopefully I didn't miss any):
http://svn.apache.org/viewcvs.cgi/apr/apr-util/trunk/include/apr_dbd.h?rev=390549&view=markup
I don't think we need to touch private functions. Users never see them
anyway. And it's always good to confuse ourselves - just when you
think you got the hang of the naming convention, the private functions
don't follow it ;-)
--
Bojan
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>
>> There's no reason for compat macros, this code has not been released
>> in any version of APR, so compat is not an issue.
>
> I was referring to renaming all DBD functions actually (including the
> new ones), so that they follow the naming proper convention (ie.
> lib_object_subobject_verb). Or is that too much to change at once?
Right - I wasn't being critical of your specific new fn, but just a general
observation. In the past, we created renames_proposed to collect a list for
review and comment before committing the changes; if you agree with the
syntax _get _set etc, then let's start that list again.
Where you took the naming from - made your choice very consistent. I was
commenting on the consistency of the libraries as a whole :)
Bill
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>> Or should we just keep the existing broken names until 2.x? It'll be
>> less hassle...
>
> My level of caring is approaching zero rapidly ;-)
He, he... Then we may as well do nothing until 2.x :-)
--
Bojan
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/2/06, Bojan Smojver <bo...@rexursive.com> wrote:
> Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>
> > 1.3.x is compatible with 1.2.x in the sense that programs compiled
> > against 1.2.x must continue to run against 1.3.x. The reverse is not
> > true, which is why in minor version number bumps we can add new
> > functions. To remove functions (or macros for that matter, although
> > that's for reasons of compile time compat, not runtime) we need to
> > bump the major version.
>
> Right. Given that, then we can have (like you said) a bunch of new
> name macros defined for all the exisiting functions with incorrect
> names in 1.3.x. The get_name functions can indeed become name_get
> immediately - there should be no harm in that.
Yep.
> And 2.x can then reverse the situation by defining backward
> compatibility macros for incorrect names and have proper new function
> names, while deprecating the old ones.
Or just drop them, that's usually what we do with deprecated stuff.
If we add new names we'll likely deprecate the old ones at the same
time.
> Or should we just keep the existing broken names until 2.x? It'll be
> less hassle...
My level of caring is approaching zero rapidly ;-)
-garrett
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Garrett Rooney <ro...@electricjellyfish.net>:
> 1.3.x is compatible with 1.2.x in the sense that programs compiled
> against 1.2.x must continue to run against 1.3.x. The reverse is not
> true, which is why in minor version number bumps we can add new
> functions. To remove functions (or macros for that matter, although
> that's for reasons of compile time compat, not runtime) we need to
> bump the major version.
Right. Given that, then we can have (like you said) a bunch of new
name macros defined for all the exisiting functions with incorrect
names in 1.3.x. The get_name functions can indeed become name_get
immediately - there should be no harm in that.
And 2.x can then reverse the situation by defining backward
compatibility macros for incorrect names and have proper new function
names, while deprecating the old ones.
Or should we just keep the existing broken names until 2.x? It'll be
less hassle...
--
Bojan
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/2/06, Bojan Smojver <bo...@rexursive.com> wrote:
> Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>
> > Well, it can be done for 1.3.x, but it would need to be by adding
> > macros for the NEW names, so the old symbols still exist at link time.
> > We can't backport such a change to 1.2.x, since it involves adding
> > new symbols.
>
> I wasn't thinking any of this would be appropriate for 1.2.x anyway.
>
> As for 1.3.x, does that mean that within major version (1.x) there can
> be no symbol loss at all, although 1.3.x isn't binary compatible with
> 1.2.x?
1.3.x is compatible with 1.2.x in the sense that programs compiled
against 1.2.x must continue to run against 1.3.x. The reverse is not
true, which is why in minor version number bumps we can add new
functions. To remove functions (or macros for that matter, although
that's for reasons of compile time compat, not runtime) we need to
bump the major version.
See http://apr.apache.org/versioning.html for details.
-garrett
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Bojan Smojver wrote:
> Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>
>> Well, it can be done for 1.3.x, but it would need to be by adding
>> macros for the NEW names, so the old symbols still exist at link time.
>> We can't backport such a change to 1.2.x, since it involves adding
>> new symbols.
>
>
> I wasn't thinking any of this would be appropriate for 1.2.x anyway.
>
> As for 1.3.x, does that mean that within major version (1.x) there can
> be no symbol loss at all, although 1.3.x isn't binary compatible with
> 1.2.x?
1.2.x-compiled apps must be binary compatible to 1.3.0 - or we have a problem.
If function arg signatures have changed, please point those out.
Of course, we need not ship 1.3.0 at all, if we believe it's better to move
forward to 2.0.0. In that version, binary compatibility isn't required.
Bill
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Garrett Rooney <ro...@electricjellyfish.net>:
> Well, it can be done for 1.3.x, but it would need to be by adding
> macros for the NEW names, so the old symbols still exist at link time.
> We can't backport such a change to 1.2.x, since it involves adding
> new symbols.
I wasn't thinking any of this would be appropriate for 1.2.x anyway.
As for 1.3.x, does that mean that within major version (1.x) there can
be no symbol loss at all, although 1.3.x isn't binary compatible with
1.2.x?
--
Bojan
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/2/06, Bojan Smojver <bo...@rexursive.com> wrote:
> Quoting Garrett Rooney <ro...@electricjellyfish.net>:
>
> > There's no reason for compat macros, this code has not been released
> > in any version of APR, so compat is not an issue.
>
> I was referring to renaming all DBD functions actually (including the
> new ones), so that they follow the naming proper convention (ie.
> lib_object_subobject_verb). Or is that too much to change at once?
Well, it can be done for 1.3.x, but it would need to be by adding
macros for the NEW names, so the old symbols still exist at link time.
We can't backport such a change to 1.2.x, since it involves adding
new symbols.
-garrett
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Garrett Rooney <ro...@electricjellyfish.net>:
> There's no reason for compat macros, this code has not been released
> in any version of APR, so compat is not an issue.
I was referring to renaming all DBD functions actually (including the
new ones), so that they follow the naming proper convention (ie.
lib_object_subobject_verb). Or is that too much to change at once?
--
Bojan
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 4/2/06, Bojan Smojver <bo...@rexursive.com> wrote:
> Quoting "William A. Rowe, Jr." <wr...@rowe-clan.net>:
>
> > When did we drift back to this naming convention?
> >
> > I thought we were trying to move twords lib_object_subobject_verb?
> >
> > E.g. apr_dbd_name_get?
> >
> > It's really aggrivating to use an api that's pulling in both directions
> > at once :(
>
> Sorry about that. I was simply trying to follow the existing
> convention inside DBD (ie. get_driver, get_row etc.). But we can
> always change the lot, define a bunch of macros for backward
> compatibility, which can then be pronounced deprecated.
>
> Would it be useful to create patches along these lines?
There's no reason for compat macros, this code has not been released
in any version of APR, so compat is not an issue.
-garrett
Re: svn commit: r390549 - /apr/apr-util/trunk/include/apr_dbd.h
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting "William A. Rowe, Jr." <wr...@rowe-clan.net>:
> When did we drift back to this naming convention?
>
> I thought we were trying to move twords lib_object_subobject_verb?
>
> E.g. apr_dbd_name_get?
>
> It's really aggrivating to use an api that's pulling in both directions
> at once :(
Sorry about that. I was simply trying to follow the existing
convention inside DBD (ie. get_driver, get_row etc.). But we can
always change the lot, define a bunch of macros for backward
compatibility, which can then be pronounced deprecated.
Would it be useful to create patches along these lines?
--
Bojan