BIND 10 #1611: ZoneFinder::find refactoring: separate normal result codes and special case flags

[BIND 10 Development]

#1611: ZoneFinder::find refactoring: separate normal result codes and special case
flags
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120207
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 Replying to [comment:7 jinmei]:
 > > First, is it OK that we're kind of inconsistent with python? When we
 had the previous version of FindResult, it acted mostly as a tuple. But
 now the C++ version has methods, while the python one has item in the
 tuple. But it is probably the easiest way to implement it.
 >
 > Good question.  I was aware of the mismatch, but I didn't fully think
 > about it.  Honestly, I don't know what's the best.  In some sense
 > using the tuple instead of a dedicated class is already a non trivial
 > difference, so this would probably not so special.  I also thought
 > that in dynamic languages like python it wouldn't make much sense to
 > prevent "abuse" via interface - that's one slight reason I used a bare
 > integer.  Also, in the vast majority cases Python applications
 > wouldn't care about the optional flags information (they would
 > basically want to know the simple result of whether a given name/type
 > exists in the zone, and if it does, what it is in the form of RRset).
 > On the other hand, I agree that it's generally better to keep these
 > two interfaces as compatible as possible.
 >
 > If you have a specific suggestion, I'm happy to hear it.  Otherwise,
 > it's probably okay to leave it open for now (especially for the last
 > reason above).

 I'm not sure. Having an object with methods as a return value of something
 to just carry the information is unusual for python. So doing it in
 completely same way as in C++ is probably a bad idea, it would surprise
 python programmers.

 There could be a hybrid approach ‒ something that'd be Iterable and still
 had the methods. So one could call it the original way, eg:
 {{{#!python
 code, rrset = finder.find(name, type)
 }}}

 or it could be used as:
 {{{#!python
 result = finder.find(name, type)
 code, rrset = result
 if result.is_wildcard():
         something()
 }}}

 However, that might be even more surprising and would need quite some code
 to create the class which is returned.

 Therefore I think keeping it the tuple way is probably the way to go, as
 it is expected from python.


 The rest of the code looks OK, so I'd think it is good for merge.

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