BIND 10 #1245: pydnspp as dynamic module (so other wrappers can use it)

[BIND 10 Development]

#1245: pydnspp as dynamic module (so other wrappers can use it)
-------------------------------------+-------------------------------------
                   Reporter:  jelte  |                 Owner:  jelte
                       Type:  task   |                Status:  reviewing
                   Priority:  major  |             Milestone:
                  Component:         |  Sprint-20110927
  libdns++                           |            Resolution:
                   Keywords:         |             Sensitive:  0
            Defect Severity:  N/A    |           Sub-Project:  DNS
Feature Depending on Ticket:         |  Estimated Difficulty:  0
        Add Hours to Ticket:  0      |           Total Hours:  0
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:9 jelte]:

 > > I've not closely looked at all the diffs, but I noticed one
 > > substantial point that I wish I could have noticed in the first
 > > review...if I understand it correctly, initModulePart_xxx()s now don't
 > > even have to be in the separate library in the first place, and that
 > > would make the code much cleaner.
 >
 > Depends on the view of clean :)

 Yeah any adjective is subjective after all:-)

 > The (only) drawback i see would be that it would be more removed from
 the actual code it covers.

 Do you mean that if we separate initModulePart_xxx() from other
 xxx-related definitions (in terms of .cc files they are defined), it
 will (e.g.) reduce readability due to the inter-file dependencies?  If
 issues like this is your concern, I understand that.

 I still prefer to hide initModulePart_xxx() from libpydnspp.  Whether
 or not it's cleaner, that will surely reduce the risk of misuse, which
 is of the biggest concern to me in this context (I don't much care
 about the size of the library - both will be used by the corresponding
 python script anyway, so it wouldn't matter much in terms of the
 actual memory footprint anyway).

 One possible compromise would be to keep the definitions in a single
 file but control which part should be active in which context using
 ifdefs.  e.g.

 {{{
 #ifdef LIBPYDNSPP
 PyMethodDef Name_methods[] = {
 ...
 };

 PyTypeObject name_type = {
 ...
 };
 #else // for pydnspp.so
 bool
 initModulePart_Name(PyObject* mod) {
 ...
 }
 #endif
 }}}

 And compile name_python.cc with LIBPYDNSPP to build libpydnspp and
 without it for pydnspp.so.

 If you think it's an ugly (which I wouldn't deny) and still also
 incline to avoid the separation, then, although I don't support the
 idea but I can live with that as a way to move forward.  In practice,
 this is a mostly internal-only module (so the risk of being misused is
 generally controllable) and the separate namespace would provide a
 sufficiently reasonable protection.

 So, I've made comments with possible options.  I'd leave the decision
 to you.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1245#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development