Ok, that's what I did in Parse::FixedLength, and Jeff Zucker did in AnyData, and it's in the constructor method, so skazat can check out those modules if he wants. I attempted to improve on how Jeff did it, but I don't know if my way was any better, but it is a little different (and it was a bit of fun to write the code in a mostly otherwise boring module :)

You have also just arbitrarily limited the naming and location of your child classes. But I don't like putting any restrictions on how things must be done ...

It's not really a restriction, its an option. In either of the modules I mentioned, you can use the subclasses directly if you want to.

Update: Actually, I'm slightly wrong. AnyData returns an object of class 'AnyData', but by passing in a string of, e.g., 'CSV', one of the elements of the object is of the class 'AnyData::Format::CSV'. But I think the same idea holds...sort of...
So AnyData does restrict the namespace of the parser, but one of these days I would like to patch AnyData to also accept a format/parser object (which might be in any namespace, as long as its compatible with the AnyData module) instead of the current 'string which maps to a fixed namespace.' Then I'd like to rewrite Parse::FixedLength to be compatible with AnyData...some day, when I get the time...