BIND 10 #2309: define ZoneFinder::findAtOrigin()

[BIND 10 Development]

#2309: define ZoneFinder::findAtOrigin()
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  6             |                 CVSS Scoring:
         Total Hours:  2.24          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei
 * totalhours:  0 => 2.24


Comment:

 Hello

 Replying to [comment:15 jinmei]:
 > Replying to [comment:14 vorner]:
 > > Also, I'm not sure I really like the idea with having a public
 interface just wrapping the `getAtOriginImpl`. Is it really likely the
 interface would change in a way the implementation could stay the same?
 What is special about this case so it is handled exceptionally? I don't
 know if it's worth the added layer of complexity. I'm not worried about
 the speed of produced code, it should be the same, since compiler will
 just inline it and optimise the call out, but the complexity of following
 the code.
 >
 > Okay, it was actually a last minute change (not the original design
 > plan), and if you don't like it I'm okay with reverting it.  And I've
 > done that.

 Thanks.

 > Regarding this design policy, I believe it's a well known practice in
 > C++ and actually suggested in some literature.  The key of the
 > decision point is how likely we'll want to change the interface for
 > the actual implementation, and, IMO, we (people in general) tend to
 > underestimate that possibility.  So, I'm basically convinced about the
 > practice.  But we don't use it in the rest of the code much anyway, so
 > in terms of consistency it may look awkward, and since this interface
 > is not expected or intended to be used by other general applications
 > (although, again, we tend to be too optimistic about such
 > expectation), I'm okay with reverting this particular case as it was
 > questioned.

 Well, the change would have to be large enough to require an interface
 change, but small enough so the wrapper function can easily map the call
 and result to the original, which sounds unlikely to me. Having a need to
 a substantial change is something I could expect, but then, the wrapper is
 useless there, since there's need to change the internal working.

 And I don't like adopting some policy just because it is suggested by some
 literature. If we followed each practice suggested somewhere, our code
 would hardly be readable (there are suggestions like type lists and
 recursive processing of them in templates!) or would take forever to
 compile (libreoffice, webkit). I like to use C++ to make code more
 readable than C, but all these policies make it less so, even when they
 have reasons to exist. Just small explanation of my motivation there.

 Anyway, thanks for the revert.

 So, I believe everything was addressed, so please merge.

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