[pacman-dev] [PATCH 00/25] Rename types from pmfoo_t to alpm_foo_t
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this. I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit Allan McRae (25): Rename pmpkgreason_t to alpm_pkgreason_t Rename pmdepmod_t to alpm_depmod_t Rename pmfileconflicttype_t to alpm_fileconflicttype_t Rename pmhandle_t to alpm_handle_t Rename pmdb_t to alpm_db_t Rename pmtrans_t to alpm_trans_t Rename pmdepend_t to alpm_depend_t Rename pmdepmissing_t to alpm_depmissing_t Rename pmconflict_t to alpm_conflict_t Rename pmfileconflict_t to alpm_fileconflict_t Rename pmgrp_t to alpm_grp_t Rename pmdelta_t to alpm_delta_t Rename pmbackup_t to alpm_backup_t Rename pmloglevel_t to alpm_loglevel_t Rename pmtransflag_t to alpm_transflag_t Rename pmtransevt_t to alpm_transevt_t Rename pmtransconv_t to alpm_transconv_t Rename pmtransprog_t to alpm_transprog_t Rename pmerrno_t to alpm_errno_t Rename pmpkgfrom_t to alpm_pkgfrom_t Rename pmgraph_t to alpm_graph_t Rename pmpkghash_t to alpm_pkghash_t Rename pmtransstate_t to alpm_transstate_t Rename pmdbinfrq_t to alpm_dbinfrq_t Rename _pmdbstatus_t to _alpm_dbstatus_t lib/libalpm/add.c | 34 +++--- lib/libalpm/add.h | 2 +- lib/libalpm/alpm.c | 12 +- lib/libalpm/alpm.h | 354 +++++++++++++++++++++++----------------------- lib/libalpm/backup.c | 16 +- lib/libalpm/backup.h | 8 +- lib/libalpm/be_local.c | 82 ++++++------ lib/libalpm/be_package.c | 30 ++-- lib/libalpm/be_sync.c | 34 +++--- lib/libalpm/conflict.c | 62 ++++---- lib/libalpm/conflict.h | 12 +- lib/libalpm/db.c | 92 ++++++------ lib/libalpm/db.h | 62 ++++---- lib/libalpm/delta.c | 68 +++++----- lib/libalpm/delta.h | 8 +- lib/libalpm/deps.c | 136 +++++++++--------- lib/libalpm/deps.h | 16 +- lib/libalpm/diskspace.c | 18 ++-- lib/libalpm/diskspace.h | 2 +- lib/libalpm/dload.c | 6 +- lib/libalpm/dload.h | 4 +- lib/libalpm/error.c | 4 +- lib/libalpm/graph.c | 8 +- lib/libalpm/graph.h | 8 +- lib/libalpm/group.c | 8 +- lib/libalpm/group.h | 4 +- lib/libalpm/handle.c | 108 +++++++------- lib/libalpm/handle.h | 20 ++-- lib/libalpm/log.c | 4 +- lib/libalpm/log.h | 2 +- lib/libalpm/package.c | 154 ++++++++++---------- lib/libalpm/package.h | 86 ++++++------ lib/libalpm/pkghash.c | 36 +++--- lib/libalpm/pkghash.h | 18 ++-- lib/libalpm/remove.c | 48 +++--- lib/libalpm/remove.h | 8 +- lib/libalpm/signing.c | 12 +- lib/libalpm/signing.h | 4 +- lib/libalpm/sync.c | 108 +++++++------- lib/libalpm/sync.h | 4 +- lib/libalpm/trans.c | 38 +++--- lib/libalpm/trans.h | 20 ++-- lib/libalpm/util.c | 14 +- lib/libalpm/util.h | 18 ++-- src/pacman/callback.c | 10 +- src/pacman/callback.h | 8 +- src/pacman/conf.c | 8 +- src/pacman/conf.h | 4 +- src/pacman/database.c | 4 +- src/pacman/deptest.c | 2 +- src/pacman/package.c | 14 +- src/pacman/package.h | 8 +- src/pacman/query.c | 36 +++--- src/pacman/remove.c | 14 +- src/pacman/sync.c | 80 +++++----- src/pacman/upgrade.c | 12 +- src/pacman/util.c | 40 +++--- src/pacman/util.h | 14 +- src/util/cleanupdelta.c | 10 +- src/util/pactree.c | 18 ++-- src/util/testdb.c | 14 +- src/util/testpkg.c | 8 +- 62 files changed, 1048 insertions(+), 1048 deletions(-) -- 1.7.6
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae <allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t? 2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Allan McRae (25): Rename pmpkgreason_t to alpm_pkgreason_t Rename pmdepmod_t to alpm_depmod_t Rename pmfileconflicttype_t to alpm_fileconflicttype_t Rename pmhandle_t to alpm_handle_t Rename pmdb_t to alpm_db_t Rename pmtrans_t to alpm_trans_t Rename pmdepend_t to alpm_depend_t Rename pmdepmissing_t to alpm_depmissing_t Rename pmconflict_t to alpm_conflict_t Rename pmfileconflict_t to alpm_fileconflict_t Rename pmgrp_t to alpm_grp_t Rename pmdelta_t to alpm_delta_t Rename pmbackup_t to alpm_backup_t Rename pmloglevel_t to alpm_loglevel_t Rename pmtransflag_t to alpm_transflag_t Rename pmtransevt_t to alpm_transevt_t Rename pmtransconv_t to alpm_transconv_t Rename pmtransprog_t to alpm_transprog_t Rename pmerrno_t to alpm_errno_t Rename pmpkgfrom_t to alpm_pkgfrom_t Rename pmgraph_t to alpm_graph_t Rename pmpkghash_t to alpm_pkghash_t Rename pmtransstate_t to alpm_transstate_t Rename pmdbinfrq_t to alpm_dbinfrq_t Rename _pmdbstatus_t to _alpm_dbstatus_t
lib/libalpm/add.c | 34 +++--- lib/libalpm/add.h | 2 +- lib/libalpm/alpm.c | 12 +- lib/libalpm/alpm.h | 354 +++++++++++++++++++++++----------------------- lib/libalpm/backup.c | 16 +- lib/libalpm/backup.h | 8 +- lib/libalpm/be_local.c | 82 ++++++------ lib/libalpm/be_package.c | 30 ++-- lib/libalpm/be_sync.c | 34 +++--- lib/libalpm/conflict.c | 62 ++++---- lib/libalpm/conflict.h | 12 +- lib/libalpm/db.c | 92 ++++++------ lib/libalpm/db.h | 62 ++++---- lib/libalpm/delta.c | 68 +++++----- lib/libalpm/delta.h | 8 +- lib/libalpm/deps.c | 136 +++++++++--------- lib/libalpm/deps.h | 16 +- lib/libalpm/diskspace.c | 18 ++-- lib/libalpm/diskspace.h | 2 +- lib/libalpm/dload.c | 6 +- lib/libalpm/dload.h | 4 +- lib/libalpm/error.c | 4 +- lib/libalpm/graph.c | 8 +- lib/libalpm/graph.h | 8 +- lib/libalpm/group.c | 8 +- lib/libalpm/group.h | 4 +- lib/libalpm/handle.c | 108 +++++++------- lib/libalpm/handle.h | 20 ++-- lib/libalpm/log.c | 4 +- lib/libalpm/log.h | 2 +- lib/libalpm/package.c | 154 ++++++++++---------- lib/libalpm/package.h | 86 ++++++------ lib/libalpm/pkghash.c | 36 +++--- lib/libalpm/pkghash.h | 18 ++-- lib/libalpm/remove.c | 48 +++--- lib/libalpm/remove.h | 8 +- lib/libalpm/signing.c | 12 +- lib/libalpm/signing.h | 4 +- lib/libalpm/sync.c | 108 +++++++------- lib/libalpm/sync.h | 4 +- lib/libalpm/trans.c | 38 +++--- lib/libalpm/trans.h | 20 ++-- lib/libalpm/util.c | 14 +- lib/libalpm/util.h | 18 ++-- src/pacman/callback.c | 10 +- src/pacman/callback.h | 8 +- src/pacman/conf.c | 8 +- src/pacman/conf.h | 4 +- src/pacman/database.c | 4 +- src/pacman/deptest.c | 2 +- src/pacman/package.c | 14 +- src/pacman/package.h | 8 +- src/pacman/query.c | 36 +++--- src/pacman/remove.c | 14 +- src/pacman/sync.c | 80 +++++----- src/pacman/upgrade.c | 12 +- src/pacman/util.c | 40 +++--- src/pacman/util.h | 14 +- src/util/cleanupdelta.c | 10 +- src/util/pactree.c | 18 ++-- src/util/testdb.c | 14 +- src/util/testpkg.c | 8 +- 62 files changed, 1048 insertions(+), 1048 deletions(-)
-- 1.7.6
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
On 28/06/11 22:32, Allan McRae wrote:
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
Do we want function names with "grp" in them to be changed too? e.g. alpm_option_add_ignoregrp, alpm_db_readgrp, alpm_db_get_grpcache, etc... That can come in a separate patchset. Allan
On Tue, Jun 28, 2011 at 8:19 AM, Allan McRae <allan@archlinux.org> wrote:
On 28/06/11 22:32, Allan McRae wrote:
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
Do we want function names with "grp" in them to be changed too? e.g. alpm_option_add_ignoregrp, alpm_db_readgrp, alpm_db_get_grpcache, etc... That can come in a separate patchset.
Yeah, I forgot to bring that into the discussion- 100% agree with just a subsequent patch adjusting these names. Not sure if you want them to be like 'ignoregroup' or 'ignore_group', 'groupcache' or 'group_cache', etc. -Dan
This probably won't change considering it's ubiquitous and insignificant, but since we're on the subject, the "_t" suffix is reserved in ISO C (or is it POSIX?). Considering the "alpm_" prefix is used it should be safe. If the suffix were to be removed might want to get rid of the typedefs (i.e. use "struct alpm_pkg" not "alpm_pkg_t"). Not really suggesting it, just thought I'd mention it. On Tue, Jun 28, 2011 at 9:19 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Jun 28, 2011 at 8:19 AM, Allan McRae <allan@archlinux.org> wrote:
On 28/06/11 22:32, Allan McRae wrote:
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
Do we want function names with "grp" in them to be changed too? e.g. alpm_option_add_ignoregrp, alpm_db_readgrp, alpm_db_get_grpcache, etc... That can come in a separate patchset.
Yeah, I forgot to bring that into the discussion- 100% agree with just a subsequent patch adjusting these names. Not sure if you want them to be like 'ignoregroup' or 'ignore_group', 'groupcache' or 'group_cache', etc.
-Dan
On Thursday, July 7, 2011, Sebastian Nowicki <sebnow@gmail.com> wrote:
This probably won't change considering it's ubiquitous and insignificant, but since we're on the subject, the "_t" suffix is reserved in ISO C (or is it POSIX?). Considering the "alpm_" prefix is used it should be safe. If the suffix were to be removed might want to get rid of the typedefs (i.e. use "struct alpm_pkg" not "alpm_pkg_t").
Not really suggesting it, just thought I'd mention it.
Can you find a source for this? I feel like most typedefs, whether in system code or user code, use the _t suffix in C code I've seen.
On Tue, Jun 28, 2011 at 9:19 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Jun 28, 2011 at 8:19 AM, Allan McRae <allan@archlinux.org> wrote:
On 28/06/11 22:32, Allan McRae wrote:
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote:
After discussion here and on IRC, it was decided that rather than changing the one struct from alpm_foo_t to pmfoo_t for consistency, it would instead be better to rename all the other structs to follow the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the best (only?) time to do this.
I am not going to send the enitre patchset here as that would just be overkill. Take a look at the patches in my repo: http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
Do we want function names with "grp" in them to be changed too? e.g. alpm_option_add_ignoregrp, alpm_db_readgrp, alpm_db_get_grpcache, etc... That can come in a separate patchset.
Yeah, I forgot to bring that into the discussion- 100% agree with just a subsequent patch adjusting these names. Not sure if you want them to be like 'ignoregroup' or 'ignore_group', 'groupcache' or 'group_cache', etc.
-Dan
Not sure which is the official source, but here's one: http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html Extract:
Some additional classes of identifier names are reserved for future extensions to the C language or the POSIX.1 environment. While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of the C or POSIX standards, so you should avoid these names. [..] Names that end with ‘_t’ are reserved for additional type names.
On Sat, Jul 9, 2011 at 4:36 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thursday, July 7, 2011, Sebastian Nowicki <sebnow@gmail.com> wrote:
This probably won't change considering it's ubiquitous and insignificant, but since we're on the subject, the "_t" suffix is reserved in ISO C (or is it POSIX?). Considering the "alpm_" prefix is used it should be safe. If the suffix were to be removed might want to get rid of the typedefs (i.e. use "struct alpm_pkg" not "alpm_pkg_t").
Not really suggesting it, just thought I'd mention it.
Can you find a source for this? I feel like most typedefs, whether in system code or user code, use the _t suffix in C code I've seen.
On Tue, Jun 28, 2011 at 9:19 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Jun 28, 2011 at 8:19 AM, Allan McRae <allan@archlinux.org> wrote:
On 28/06/11 22:32, Allan McRae wrote:
On 28/06/11 22:17, Dan McGee wrote:
On Tue, Jun 28, 2011 at 12:23 AM, Allan McRae<allan@archlinux.org> wrote: > > After discussion here and on IRC, it was decided that rather than > changing the one struct from alpm_foo_t to pmfoo_t for consistency, > it would instead be better to rename all the other structs to follow > the alpm_foo_t scheme. Given we are pushing towards 4.0, now is the > best (only?) time to do this. > > I am not going to send the enitre patchset here as that would just be > overkill. Take a look at the patches in my repo: > http://projects.archlinux.org/users/allan/pacman.git/log/?h=breakshit
Two observations: 1. Where is pmpkg_t?
In with pmtrans_t for some reason... will fix!
2. Does anyone else find "grp" kind of silly? pkg is ubiquitous and at least less than 50% of the length of package, but I might propose shifting the type name to "alpm_group_t".
Seems reasonable to me. I can adjust this.
Do we want function names with "grp" in them to be changed too? e.g. alpm_option_add_ignoregrp, alpm_db_readgrp, alpm_db_get_grpcache, etc... That can come in a separate patchset.
Yeah, I forgot to bring that into the discussion- 100% agree with just a subsequent patch adjusting these names. Not sure if you want them to be like 'ignoregroup' or 'ignore_group', 'groupcache' or 'group_cache', etc.
-Dan
On Sat, Jul 9, 2011 at 9:51 AM, Sebastian Nowicki <sebnow@gmail.com> wrote:
Not sure which is the official source, but here's one: http://www.gnu.org/s/hello/manual/libc/Reserved-Names.html
Extract:
Some additional classes of identifier names are reserved for future extensions to the C language or the POSIX.1 environment. While using these names for your own purposes right now might not cause a problem, they do raise the possibility of conflict with future versions of the C or POSIX standards, so you should avoid these names. [..] Names that end with ‘_t’ are reserved for additional type names.
Good to know, thanks for the link. I'd probably say we are fine as we now use the same prefix on all of our exported symbols, so our chance of being in conflict with any future type name or function is slim to none. -Dan
participants (3)
-
Allan McRae
-
Dan McGee
-
Sebastian Nowicki