BIND 10 #2376: define LoaderContext class
BIND 10 Development
do-not-reply at isc.org
Mon Nov 19 15:11:24 UTC 2012
#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 |
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Hello
Replying to [comment:17 jinmei]:
> As I already said, I would like to separate the error callbacks and
> the add callback. The former will be passed to rdata constructors,
> and it would look awkward if it contained something related to
> `RRset`.
I understand it in the case of the context, which is somehow heavyweight
and
primarily oriented towards adding RRsets. But with this lightweight almost
struct, I don't see the real problem. If the Rdata constructors act the
same
way as html renderers ‒ if you don't understand it, ignore it ‒ it should
be no
problem. It might seem slightly odd, but if we split it, it will become
less
convenient to use.
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).
* 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.
--
Ticket URL: <http://bind10.isc.org/ticket/2376#comment:19>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list