[bind10-dev] python bindings

[Shane Kerr]

Jinmei,

On Thu, 2009-12-17 at 00:13 -0800, JINMEI Tatuya / 神明達哉 wrote:
> I'd be more interested in whether to implement the hash algorithm,
> developing an in-house library (like BIND9) or using an existing one,
> rather than which algorithm.  (in this sense my original question
> wasn't well described).  I guess in AFTR you chose jhash as the
> algorithm and implemented (ported?) it as an in-house library.  I
> thought we'd avoid the in-house approach where possible.

Yes, we'd like to avoid the in-house approach. Sadly the C++ STL has no
hash built in, so may I humbly suggest we use Boost unless there is some
compelling reason not to?

http://bytes.com/topic/c/answers/630022-stl-hash-function-where-header

> > > Please refer to branches/jinmei-dnsmessageapi.  It's what I'm going to
> > > get reviewed (and mostly ready for that).
> > 
> > => can you make the default constructor (Name::Name()) available?
> > It is possible to call a constructor from python __init__ but only
> > one of them and here you have two (from text or wire).
> > (note I'll try to find a way to use factory functions but ...)
> 
> Hmm...I actually thought about whether we need to make the default
> constructor public.  The reason why I made it private in the current
> branch is because the default constructor makes an empty name (i.e., a
> name object with no labels).  If we allow applications to construct a
> name that way we need to handle such cases in other methods, making
> the code complicated.  So, I chose to keep it private at the moment
> until there's a strong reason to make it public.
> 
> I'm not sure if this is strong enough to have a public default
> constructor.  But if we encounter another case, possibly in other part
> of the C++ version of the API, where we'd need it, I'll make that
> change.

This makes sense to me. We shouldn't allow objects to be instantiated
that make no sense. :)

--
Shane