Hi Chris, I think Regexp::Common is nice, but there are several aspects of that solution I am not too keen on.
1. The solutions are not regular expressions, perhaps the validation could be implemented as regular expressions, but since they contain calculations I do not know whether this is possible and if possible a good idea, the algorithms are written in clean, maintainable code with a test coverage close to 100% 2. I will be dependent on a different release cycle than one I could control myself - some of these modules are used in my everyday business and therefore I would like to be able to control them to some extent - CPAN would be used for sharing/distributing the work, the knowledge is simple to not say trivial. One of the reasons why I raise this issue is that you seem concerned about the activity level of Regexp::Common and it's maintenance. Another reason is that I like the idea of small and specialized tools/modules. Anyhow I will have a look at Regexp::Common::SEN to see whether I can contribute with anything anyway. jonasbn > On Feb 9, 2006, at 5:14 AM, A. Pagaltzis wrote: > >> Hi Jonas, >> >> * Jonas B. Nielsen <[EMAIL PROTECTED]> [2006-02-09 11:35]: >>> Algorithm seems like the more general one, but since it is not >>> hard science simply modulus gymnastics and it is not security, >>> but mere validation and generation. >> >> in a sense, everything is an algorithm. :-) I see Algorithm:: as >> the place for things whose purpose it is to perform some abstract >> operation on a specific data structure. This is fuzzy, I know; a >> more solid definition would be difficult to give, if it is at all >> possible. >> >> Your code is not an algorithm in that abstract sense, though. >> Business::DK::* sounds perfect to me. >> >> Regards, >> -- >> Aristotle Pagaltzis // <http://plasmasturm.org/> > > > I agree with Aristotle's reasoning. I further suggest you try to > work your algorithms into existing modules. For example: > > Regexp::Common::SEN - provide regexes for Social-Economical Numbers > http://search.cpan.org/~abigail/Regexp-Common-2.120/lib/Regexp/ > Common/SEN.pm > This currently lacks a Danish entry, so your contribution would be > extremely valuable > > Regexp::Common::zip - provide regexes for postal codes > http://search.cpan.org/~abigail/Regexp-Common-2.120/lib/Regexp/ > Common/zip.pm > Danish postal codes are already present. Here's the code at present: > > Denmark => "(?k:(?k:[1-9])(?k:[0-9])(?k:[0-9]{2}))", > # Postal codes of the form: 'DDDD', with the first > # digit representing the distribution region, the > # second digit the distribution district. Postal > # codes do not start with a zero. Postal codes > # starting with '39' are in Greenland. > > The advantage of adding your code into Regexp::Common is that R::C is > very popular, and your work would likely benefit more people than if > you were to create a brand new package. And perhaps some new energy > would push Abigail et al. to finally release an updated version which > could address some of the RT bugs, like getting Javadoc added to > Regexp::Common::comment > > Chris > -- > Chris Dolan, Software Developer, Clotho Advanced Media Inc. > 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 > vCard: http://www.chrisdolan.net/ChrisDolan.vcf > > Clotho Advanced Media, Inc. - Creators of MediaLandscape Software > (http://www.media-landscape.com/) and partners in the revolutionary > Croquet project (http://www.opencroquet.org/) > > > > -- Jonas B. Nielsen Founder of logicLAB [EMAIL PROTECTED] || http://www.logicLAB.dk/ (+45 26787275)
