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...
In reply to Re: Re (tilly) 3: Loading a different Module depending on the Configuration
by runrig
in thread Loading a different Module depending on the Configuration
by skazat
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |