While writing CGI::Search, I wanted to make validating CGI input a very basic part of the module (making it so integerated into it that there'd be no excuse for not doing it). As a general rule, the data would be untainted after coming out of validation (though the module itself doesn't do much that would require untainting). There were a few built-in validators, but I wanted users to be able to create their own.

My initial thought was to pass in a regex match (via qr//). However, while regexen might be rather powerful, they just aren't good enough.

The real solution was to pass in a referance to a subroutine. There are a few requirements that a custom validator must have (takes in the data to be validated as its only argument, returns a three-element list (a boolean value indicating success or failure, the untainted data (if successful), and a string that can be used as an error message on failure)).

Later, I discovered the WWW::FieldValidator module. This takes things further than CGI::Search does, in that you can specify the use of either some built-in validation, a regex match, or a subroutine referance. Also, you can pass in an array ref containing mutilple validators, so that a single peice of data must mach all the validators you pass. Replacing CGI::Search's validation sementics with WWW::FieldValidator is on my TODO list.

Finally getting to the point--like many things in software, flexibility is a more evolutionary process than something that comes in a flash of insight. Using a regex wasn't quite powerful enough, but it was simple. Subroutines were powerful, but lost much of the simplicity. The real soultion, as WWW::FieldValidator showed me, was to support both.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated