[ 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.