you have to subclass XML::Twig when what you want to subclass is really XML::Twig::Elt. This is probably better from a pure OO POV (is-it? Would any OO purist care to comment?), but a tad more verbose.

I don't think either solution is more or less pure than the other. It depends on how you see people using the feature.

My immediate feeling was that you would want to subclass XML::Twig since you would want to reuse the parser variant, rather than having to remember to pass the appropriate XML::Twig::Elt subclass in each time. Once And Only Once and all that.

If you're going to be creating lots of one-off XML::Twig parsers passing the class as you originally proposed would probably be more sensible.

I would think it is a little slower too, as you add a layer of method calling instead of just a test on a field of the object. I would have to benchmark the 2 ways and compare them.

It would be trivial to cache the result of the method to reduce it to the hash-lookup case:

# in XML::Twig::add_elt
my $elt_class = $self->{elt_class} ||= $self->elt_class;
my $e = $elt_class->new ;
[download]

There is, of course, nothing stopping you having both mechanisms so you can subclass, or change it on an object-by-object basis. That way everybody's happy :-)