You might also consider making the configuration an object member instead of a class member. Then you could have multiple, differently configured Form::Validator objects in existence at the same time. Here's how it would work:

package Form::Validator;

sub new {
   ...
   $self->{allowed_tags} = []; # initially empty
}

sub SetConfig {
   my $self = shift;
   $self->{allowed_tags] = [ @_ ];
}

package WebSite1::FormValidator;

my $fv = new Form::Validator();
$fv->SetConfig(qw(a input ...));
...

package WebSite2::FormValidator;

my $fv = new Form::Validator();
$fv->SetConfig(qw(...));
[download]

You could also make the configuration a constructor parameter.

Subclassing to change configuration seems like a poor use of subclassing. You shouldn't create a subclass in order to change the data values in an object. If you later had some better reason to use inheritance you'd have to fit your inheritance into a existing tree of classes, which would likely be very complicated if you got it to work at all. Inheritance is best reserved more as a "last resort" in a design. The "is a" relationship is too inflexible and so should be invoked sparingly.

I hate Repeat::The::Really::Long::Class::Name->new() syntax. Package names should be very clear and globally unique and you should only ever mention them once in your code. I much prefer to have a (pre-configure) factory for constructing any objects:

my $Valid;
use Form::Validator(
    Factory=>\$Valid,
    AllowedTags=>[...],
    OtherConfig=>...,
    ...,
);

# ...

    my $obj= $Valid->new( ... );
[download]

That way you can use the same module two or more ways from the same code. You can store your pre-configured factory in a file-scope lexical, a package global, as a member of each object, anywhere you can store a lexical.

And, in practice, in Perl, it is often natural to just allow any object to be a factory for its own class. $obj->new( ... ) creates a new object using the configuration information from $obj. Then you may want a way to create a pre-configured but empty object to use just as a factory.

Of the three solutions mentioned so far, I like yours the most - it's clean and flexible. The only downside is that you need to make the $Valid object available wherever you want to use the module. But, if you consider this to be in the league of "configuration data", then you would usually be doing that anyway, so no biggie.

thanks Tye

It occurred to me, after posting the above reply, that the one situation where this doesn't help is with class methods, when the method isn't expecting an object. A class method may require (eg) a base directory, or some other setting which will vary per application, but that you don't want to have to pass in on every use.

Clint

package FormValidator;
use strict;
use warnings;

my %conf;#{app_id1=>conf1,app_id2=>conf2}
sub new {
  my ($class,$conf,$app_id) = @_
  $app_id = $ENV{APP_ID} unless defined $app_id;
  $conf{$app_id} = $conf if defined $conf;
  return bless $conf{$app_id}, $class;
}
[download]

#first application
$ENV{APP_ID} = 'APP_1';
my $obj_1 = FormValidator->new({foo=>'bar'});
my $obj = FormValidator->new();
print $$obj{foo};#prints 'bar'

#second application
my $obj_2 = FormValidator->new({foo=>'BAZ'},'APP_2');
my obj = FormValidator->new();
print $$obj{foo};#prints 'BAZ'
[download]