BIND 10 #2376: define LoaderContext class
BIND 10 Development
do-not-reply at isc.org
Wed Nov 21 13:05:07 UTC 2012
#2376: define LoaderContext class
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: reviewing
Type: task | Milestone:
Priority: | Sprint-20121204
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 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Hello
Replying to [comment:20 jinmei]:
> > If you still think it is worth splitting it off, there could be two
options:
> > * Passing two separate parameters to the MasterLoader constructor
(the less convenient way).
>
> Personally I don't see a problem with this - as I said above, the
> tradeoff for the split approach is independent from the complexity of
> the context or the call back class/struct to me. But that's probably
> a matter of preference.
OK, I split it off.
> > * Inheritance. The class containing the issues is the base class and
then
> > there's a derived class adding the add callback. The master loader
gets the
> > derived one, which gives it all the needed callbacks. Then the
constructors
> > take only the base one, getting only the issue ones.
>
> This doesn't seem to be a good use of inheritance IMO.
I don't really see reason why it wouldn't be a good use of inheritance.
Maybe
slightly unusual, but very much by the rules and recommendations ‒ things
are
only added, and it would specialize generic error callbacks to master
loader
callbacks.
--
Ticket URL: <http://bind10.isc.org/ticket/2376#comment:22>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list