Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
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
On 4/2/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
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
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
On 4/2/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
On 4/2/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
On 4/2/06, Bojan Smojver [EMAIL PROTECTED] wrote:
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
Bojan Smojver wrote:
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
Bojan Smojver wrote:
Quoting Garrett Rooney [EMAIL PROTECTED]:
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
Quoting William A. Rowe, Jr. [EMAIL PROTECTED]:
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,
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
[EMAIL PROTECTED] wrote:
Author: niq
Date: Fri Mar 31 16:28:12
12 matches
Mail list logo
