You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Chris Darroch (JIRA)" <ji...@apache.org> on 2009/02/05 20:45:59 UTC
[jira] Created: (ZOOKEEPER-295) prevent multiple namespace
pollution by C API
prevent multiple namespace pollution by C API
---------------------------------------------
Key: ZOOKEEPER-295
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-295
Project: Zookeeper
Issue Type: Improvement
Components: c client
Affects Versions: 3.0.1, 3.0.0, 3.1.0
Reporter: Chris Darroch
The ZOOKEEPER-6 issue touched on the problem of namespace pollution by the ZooKeeper C API; this report was closed but I don't think the problem has actually been substantially resolved.
There are multiple namespaces to consider. First, the names of the C include files should ideally have a common prefix, e.g., zoo_recordio.h, or else be concatenated into a single zookeeper.h file. The zookeeper.jute.h include file has a reasonably good name in this regard.
Second, all macros should ideally have a common prefix, e.g., ZOO_ or ZK_ or ZOOKEEPER_. Currently many exported constants (not macros) have the ZOO_ prefix, such as ZOO_PERM_READ, but error codes have a Z prefix, e.g., ZOK, ZNOTEMPTY.
Third, all functions should ideally have a common prefix, e.g., zoo_ or zk_ or zookeeper_. Many do already, but there is some variation, such as zookeeper_init(), zookeeper_process(), and there are also a large number of functions which have no prefix. These include many of the functions defined in recordio.h and zookeeper.jute.h, such as get_buffer() and serialize_Id(). Many others are simply used internally within the ZooKeeper C library and not declared in an external include file, but still pollute the caller's namespace, e.g., get_xid(), process_completions(), adaptor_init(), etc. All external symbols in the libraries should have a common prefix.
Fourth, all structure and type definitions should also have a common prefix, again, zoo_ or zk_ or zookeeper_. This is especially true of structures which currently have very generic names such as Id, Stat, and ACL from zookeeper.jute.h; buffer, iarchive, and oarchive from recordio.h; and clientid_t and watcher_fn from zookeeper.h. The zhandle_t structure should also be renamed to have the same prefix, e.g., zoo_handle_t.
The ZOOKEEPER-6 report includes the comment that the names in zookeeper.jute.h will be difficult to change because they affect the Java code and that there should be "limited exposure since jute naming starts with caps". It would be nice to think so, but I fear that a structure named Id or Stat is going to be pretty darn commonplace in other people's code. I would strongly recommend revising the entire set file, function, macro, type and structure names for 4.0.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-295) prevent multiple namespace
pollution by C API
Posted by "Maxim P. Dementiev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795046#action_12795046 ]
Maxim P. Dementiev commented on ZOOKEEPER-295:
----------------------------------------------
Completely agree.
Let's take zerror function name.
It was used by many zip/unzip C implementations and linking the whole project (which uses both zk and zip) causes errors.
> prevent multiple namespace pollution by C API
> ---------------------------------------------
>
> Key: ZOOKEEPER-295
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-295
> Project: Zookeeper
> Issue Type: Improvement
> Components: c client
> Affects Versions: 3.0.0, 3.0.1, 3.1.0
> Reporter: Chris Darroch
> Fix For: 4.0.0
>
>
> The ZOOKEEPER-6 issue touched on the problem of namespace pollution by the ZooKeeper C API; this report was closed but I don't think the problem has actually been substantially resolved.
> There are multiple namespaces to consider. First, the names of the C include files should ideally have a common prefix, e.g., zoo_recordio.h, or else be concatenated into a single zookeeper.h file. The zookeeper.jute.h include file has a reasonably good name in this regard.
> Second, all macros should ideally have a common prefix, e.g., ZOO_ or ZK_ or ZOOKEEPER_. Currently many exported constants (not macros) have the ZOO_ prefix, such as ZOO_PERM_READ, but error codes have a Z prefix, e.g., ZOK, ZNOTEMPTY.
> Third, all functions should ideally have a common prefix, e.g., zoo_ or zk_ or zookeeper_. Many do already, but there is some variation, such as zookeeper_init(), zookeeper_process(), and there are also a large number of functions which have no prefix. These include many of the functions defined in recordio.h and zookeeper.jute.h, such as get_buffer() and serialize_Id(). Many others are simply used internally within the ZooKeeper C library and not declared in an external include file, but still pollute the caller's namespace, e.g., get_xid(), process_completions(), adaptor_init(), etc. All external symbols in the libraries should have a common prefix.
> Fourth, all structure and type definitions should also have a common prefix, again, zoo_ or zk_ or zookeeper_. This is especially true of structures which currently have very generic names such as Id, Stat, and ACL from zookeeper.jute.h; buffer, iarchive, and oarchive from recordio.h; and clientid_t and watcher_fn from zookeeper.h. The zhandle_t structure should also be renamed to have the same prefix, e.g., zoo_handle_t.
> The ZOOKEEPER-6 report includes the comment that the names in zookeeper.jute.h will be difficult to change because they affect the Java code and that there should be "limited exposure since jute naming starts with caps". It would be nice to think so, but I fear that a structure named Id or Stat is going to be pretty darn commonplace in other people's code. I would strongly recommend revising the entire set file, function, macro, type and structure names for 4.0.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-295) prevent multiple namespace
pollution by C API
Posted by "Patrick Hunt (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Patrick Hunt updated ZOOKEEPER-295:
-----------------------------------
Fix Version/s: 4.0.0
sounds good for 4
> prevent multiple namespace pollution by C API
> ---------------------------------------------
>
> Key: ZOOKEEPER-295
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-295
> Project: Zookeeper
> Issue Type: Improvement
> Components: c client
> Affects Versions: 3.0.0, 3.0.1, 3.1.0
> Reporter: Chris Darroch
> Fix For: 4.0.0
>
>
> The ZOOKEEPER-6 issue touched on the problem of namespace pollution by the ZooKeeper C API; this report was closed but I don't think the problem has actually been substantially resolved.
> There are multiple namespaces to consider. First, the names of the C include files should ideally have a common prefix, e.g., zoo_recordio.h, or else be concatenated into a single zookeeper.h file. The zookeeper.jute.h include file has a reasonably good name in this regard.
> Second, all macros should ideally have a common prefix, e.g., ZOO_ or ZK_ or ZOOKEEPER_. Currently many exported constants (not macros) have the ZOO_ prefix, such as ZOO_PERM_READ, but error codes have a Z prefix, e.g., ZOK, ZNOTEMPTY.
> Third, all functions should ideally have a common prefix, e.g., zoo_ or zk_ or zookeeper_. Many do already, but there is some variation, such as zookeeper_init(), zookeeper_process(), and there are also a large number of functions which have no prefix. These include many of the functions defined in recordio.h and zookeeper.jute.h, such as get_buffer() and serialize_Id(). Many others are simply used internally within the ZooKeeper C library and not declared in an external include file, but still pollute the caller's namespace, e.g., get_xid(), process_completions(), adaptor_init(), etc. All external symbols in the libraries should have a common prefix.
> Fourth, all structure and type definitions should also have a common prefix, again, zoo_ or zk_ or zookeeper_. This is especially true of structures which currently have very generic names such as Id, Stat, and ACL from zookeeper.jute.h; buffer, iarchive, and oarchive from recordio.h; and clientid_t and watcher_fn from zookeeper.h. The zhandle_t structure should also be renamed to have the same prefix, e.g., zoo_handle_t.
> The ZOOKEEPER-6 report includes the comment that the names in zookeeper.jute.h will be difficult to change because they affect the Java code and that there should be "limited exposure since jute naming starts with caps". It would be nice to think so, but I fear that a structure named Id or Stat is going to be pretty darn commonplace in other people's code. I would strongly recommend revising the entire set file, function, macro, type and structure names for 4.0.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.