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:  jinmei
                       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:5 jelte]:

 > > '''general'''
 > >
 > > - I'd suggest hiding initModulePart_xxx() as much as possible because
 > >   they are essentially private internal subroutines for
 > >   PyInit_pydnspp() and are not expected to be called by any others
 > >   (right?).  Specifically, I'd move the declaration of them from
 > >   the semi-public header files such as edns_python.h to some special
 > >   header files such as edns_python_internal.h with comments that they
 > >   shouldn't be included in any other files outside the pydnspp module.
 > >   I'd also "hide" the declaration and definition of these
 > >   initModulePart functions in a deeper namespace such as
 > >   isc::dns::python::internal.
 > >
 >
 > I moved them to isc::dns::python::internal. I also created a separate
 _internal
 > header file for each file, when I realized that this isn't actually
 really that
 > useful; I opted to define them as forward declarations in pydnspp.cc.
 This way
 > we save the 'pollution' of another 17 files, and they can't be included
 by
 > accident. We *could* make a pydnspp.h that does it, but this way seems
 fine to
 > me.

 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.

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