On Fri, Oct 27, 2000 at 11:45:15AM +0100, Tim Bunce wrote:
> On Thu, Oct 26, 2000 at 11:26:25PM +0200, Andreas J. Koenig wrote:
> > >>>>> On Tue, 17 Oct 2000 09:07:50 -0500, Dave Plonka <[EMAIL PROTECTED]> said:
> >
> > > Kurt, thanks for the feedback.
> > > Considering Net::Patricia vs. Tree::Patricia...
> >
> > > On Mon, Oct 16, 2000 at 05:43:08PM -0400, Kurt D. Starsinic wrote:
> > >> On Mon, Oct 16, 2000 at 12:19:42PM -0500, Dave Plonka wrote:
> > > <snip>
> > >> > I think it belongs in the Net namespace because it requires that the
> > >> > search keys must consist of IP addresses and netmasks, and the
> > >> > underlying C code on which it is based requires that as well. I.e.
> > >> > this module is not a general Trie implementation like Text::Trie or
> > >> > Tree::Trie.
> > >>
> > >> It seems to me that it would be more appropriate as, e.g.,
> > >> Tree::Patricia. It doesn't implement network protocols, rather it
> > >> manipulates data structures. The fact that the elements of the
> > >> data structure _can_ obviously be interpreted as CIDR addresses and
> > >> netmasks doesn't prevent one from coming up with more dastardly uses
> > >> for the module.
> >
> > > I agree with the assessment that Patricia is a data structure not
> > > network protocol. However, there are precedents such as Net::Netmask
> > > and Net::IPv4Addr of which one could say the same.
> > > Do those modules not belong in Net? [rhetorical]
> >
> > Bad precedent is ubiquitous on CPAN:-/
>
> Sad but true.
>
> > > I'm not against the Patricia module being in Tree::Patricia, but there
> > > are other complications... The C code on which the module is based
> > > looks like networking code in that it currently uses inet_addr(3) and
> > > therefore requires "<arpa/inet.h>" and "-lnsl". I could follow
> > > Socket.pm's lead and reimplement a private/static inet_addr within to
> > > eliminate that requirement, but avoiding the system-provided library
> > > routines in these way could make it harder to maintain, esp. when I
> > > pass-thru IPv6 addr support to the perl API.
> >
> > Strong arguments.
>
> I'd also remind folks that names should be based on what functionality
> a module offers, not how it's implemented.
In the case of a module named such that it must implement its
functionality by a specific data structure and algorithm, the
functionality and implementation are necessarily intertwined.
For Net::Patricia, if the functionality I was attempting to provide did
not have performance implications, I might have called it Find::Prefix
or some such thing. Actually, if that were case we wouldn't be having
this discussion because Net::Netmask's order-of-magnitude slower
sequential search would have been sufficient.
It was the Right Thing for us to consider Tree::Patricia as Kurt
suggested. I did that, and I discussed it with other perl hackers. As
he pointed out, this module *could* be used for other key values that
have the same syntax (and nearly the same semantics). Specifically he
said:
[Net::Patricia's API] doesn't prevent one from coming up with more
dastardly uses for the module.
When a programmer finds a *dastardly use* for a standard API, we
usually call it a kludge. In which case it is almost preferable that
that API seems inappropriate for that use. I.e. if someone use
Net::Patricia to lookup something weird, perhaps machine language
op-code prefixes or something, the code should look weird so that
maintainers say "Why is this program using Net::Patricia"?
So CPAN allowing me to advertise my module as Net::Patricia is useful
to me as the author, and it suggests that perl hackers only use it as
intended and to be very careful using it for other purposes. While I'm
all for reuse, all bets are off if you don't use Net::Patricia for IP
addresses and netmasks.
> > > At the moment, I'm still leaning toward Net::Patricia because of the
> > > underlying networking requirements.
> >
> > We are all starting to react allergically against Net:: because it
> > becomes a bit basket, it's crowded there. But I see you arguments in
> > favor and I see you have uploaded version 1.009. I tend to accept
> > Net:: based on your arguments.
>
> Joining the ubiquitous bad precedents ;-)
When someone writes the more ambitious general PATRICIA trie (as is
apparently described in Sedgewick, I don't even have the book), it can
be called Tree::Patricia. If and when that happens, I think we'll all
be glad that Net::Patricia is where it is now because Tree::Patricia
will be more general, but will probably perform more slowly upon keys
in the IP address space, so the need for both remains.
> Tim.
>
> p.s. I don't feel very strongly about this, just wanted to remind folks
> about the 'ignore implementation issues' line of reasoning for the future.
Understood, I just don't think Net::Patricia is the poster boy for that
cause. Believe it or not, I spent weeks (on and off) on the namespace
issue which is apparently more time than many have either the
motivation or the luxury of expending. So we're glad the modules list
participants to help out.
Dave
--
[EMAIL PROTECTED] http://net.doit.wisc.edu/~plonka ARS:N9HZF Madison, WI
