BIND 10 #2376: define LoaderContext class

[BIND 10 Development]

#2376: define LoaderContext class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121120
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:12 vorner]:

 The code looks okay and can be merged, except for the design discussion.

 > > I guess the question is how we expect the concept of "loader context"
 > > will be complicated, including more states.  In our current usage,
 > > that's basically identical to the imaginary `addRRset` functor object,
 > > so it may make more sense to skip the additional layer of the class.
 > > On the other hand, if we anticipate the context can have more
 > > complicated states, it probably makes more sense to define a separate
 > > class (as we do now) than passing each of them as a parameter to
 > > `MasterLoader`.
 >
 > I don't see what kind of state there could actually be.
 >
 > I'm not against moving to the mailing list. Will you start the thread or
 should I?

 Please start it as you should have a stronger motivation for it.

 > > - I guess we can simply use true-false check for boost::function
 > >   objects:
 > > {{{#!cpp
 > >         if (!error_ || !warning) {
 > >             isc_throw(isc::InvalidParameter,
 > >                       "Empty function passed as callback");
 > >         }
 > > }}}
 >
 > Well, I think that if we don't allow treating pointers like true-false
 and
 > explicitly test for NULL, this is very similar. So I didn't adopt this
 one.

 In this case we actually first convert them to bool via operator!().
 The use of such less explicit operators could itself be controversial
 (which would be more so for type conversion operators) though, so I'm
 not necessarily pushing the use of it.  I just wanted to note that
 boost::function has this operator for this purpose.

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