Hi, thanks for pointing that out. Patch committed to SVN
Peter On Friday, 20. January 2006 19:58, [EMAIL PROTECTED] wrote: > Peter, > > Peter Marschall schreef: > > Hi, > > > > On Wednesday, 18. January 2006 21:30, [EMAIL PROTECTED] wrote: > >> sounds like a reasonable wish ( see attached patch ;-) > >> Allowing developers to specify their own matching module instead of the > >> ones we pre-cooked is a little tricky since every module uses a > >> different name for the match method and other peculiarities. > >> We could allow for: > >> > >> use Net::DLAP::FilterMatch Text::Soundex=>soundex; > >> > >> or > >> > >> use Net::DLAP::FilterMatch qw(Text::Soundex::soundex); > >> > >> > >> But this becomes rather messy given the differences between modules, if > >> someone really wants something special he can always override the > >> _cis_approxMatch sub. What do you think ? > > > > I am happy with the current implementation in your patch. > > > > I do not think we need to allow any kind of approx matching module. > > The three we have now should cover a broad range of applications. > > > > Patch applied with a few changes: > > - rename @Plugins (in "use vars" line) to @approxMatchers to have > > one name for the beast > > - reorder lines a bit: move "use vars" line before using the vars. > > > > CU > > Peter > > I appreciate your eye for detail regarding the vars, however the > reordering of the code broke the module. > The import must be in the Net::LDAP::FilterMatch section or else it will > not be called on import. > > To ensure that I catch the vars errors myself (:-) I have made the > module strict again. That should cover most of these kind of typo's. > > The attached patch repairs the import and also covers the strictness. > > Cheers, > > Hans > ps.if I find the time I'll try to make a test for this module. -- Peter Marschall eMail: [EMAIL PROTECTED]
