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
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:17 vorner]:

 > > 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.

 Everything is tradeoff for this type of topics, so I'd just say both
 possibilities can happen.  Ultimately we need to make a decision
 case-by-case basis.

 > 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.

 I don't understand how my comment about was interpreted as adopting a
 policy "just because" it is suggested by some literature.  Rather, I
 thought I explained why I'm personally convinced that it's a good
 practice.  Anyone can disagree with my conviction itself, of course,
 but I never intended to insist we should adopt it "because it's
 suggested by literature".  I mentioned literature only to show its not
 just my personal preference, but subjectively supported by (some)
 others.  It's needless to say not everything in the literature is a
 good suggestion, or it can simply be the case where we just don't like
 some (with some reasonable reason).  It's simply naive to follow what
 the literature says even in such cases, but it's also silly to just
 dismiss widely recognized practice merely because of personal taste;
 smart people tend to think they know what is correct, but in my humble
 opinion it's often that they just don't know what others think.

 In any case, I don't think I've ever suggested anything "just because"
 it's written in some literature, and I believe I won't either.  So,
 it'd make discussions smoother if you don't misunderstand the point.

 Anyway, merge done, now closing the ticket.

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