[bind10-dev] #2376 and more lightweight approach
JINMEI Tatuya / 神明達哉
jinmei at isc.org
Tue Nov 13 18:39:22 UTC 2012
I'd like to get someone else's opinion as I was involved in #2376 too,
but anyway:
At Tue, 13 Nov 2012 12:40:49 +0100,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> I'm bit worried about useless layers of glue classes that do nothing in our
> code. I can find them from time to time and I believe they are hard to read whet
> someone who does not know the code finds them.
I think it's case by case basis. Whether it's useful to introduce a
particular glue layer using a separate class (especially an abstract
base class with inheritance) often depends on how much design
flexibility we need as the implementation evolves. Often it's not
really clear from the beginning, so it can turn out to be either a
premature abstraction or nice foresight.
> This will allow it to be passed conveniently around to the RR factories.
>
> And possibly put both callbacks together into a std::pair. So we could have:
>
> typedef boost::function<void (const std::string&, size_t, const std::string&)>
> IssueCallback;
> typedef boost::function<void (const RRsetPtr&)> AddRRsetCallback;
> typedef std::pair<AddRRsetCallback, IssueCallback> LoaderCallbacks;
>
> This has one disadvantage. It is harder to extend with some kind of state or
> more callbacks. But, I don't really see a place where more callbacks or state
> would fit in.
>
> What is your opinions?
In this case I'm okay with the functor approach; I'm not so sure if
"add RRset" is the only interface we'll need, but I don't have a
specific other ideas either. I have no opinion about whether to
combine/separate the error/warn callbacks. I don't see the need for
combining the add callback and error/warn callbacks, but if we do so,
I'd rather use a struct than pair. After all pair is just a struct
for exactly two members, and I don't see much advantage in restricting
the number of members in this case.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
More information about the bind10-dev
mailing list