Re (tilly) 3: Loading a different Module depending on the Configuration

No unless. Method calling is fully dynamic, you don't have to hardcode the package anywhere. If you want to get abusive about it you can even do something like this:

my $pack = "Foo";
my $meth = "new";
my $obj = $pack->$meth(); # Calls method new in class Foo
[download]

So you can pass the buck to the client code, knowing that if they need to be dynamic, they still can, but it will still be simpler in the common case, and the base class will not need maintainance as you add child classes.

UPDATE
I think there is more than just a preference here. If you choose to pass the subpackage in as a string, the parent class has to do a lot more. For one thing I would now demand that it loads the child class. Which means that either the parent has to hardcode all of its children (maintainance issues anyone?), or you have to write dynamic loading logic. You have also just arbitrarily limited the naming and location of your child classes. In many cases this may be innocuous. But I don't like putting any restrictions on how things must be done unless I see very specific benefits to doing it.

Therefore I don't see the different structure as being a benefit in any way, shape, or form.

However it bears costs. You have to write more code for the feature. That is more code to write, debug, test, and be aware of. You now have objects that are not blessed into the class which people would expect them to be blessed into. It is now harder to subclass an arbitrary part of your hierarchy. Someone who wants to understand your code now has to do extra work to figure out your data structure.

This is not to say that you might not from time to time want to have dynamic loading of specific subclasses. DBI's proxying off of appropriate DBD::* classes is an excellent case in point. However such cases are somewhat exceptional. And furthermore if ever I have the choice between a minor aesthetic issue and managing to write the most naturally straightforward code possible which achieves the goal, I retrain my aesthetics! Unnecessary complications are a bad idea in my books.

Comment on Re (tilly) 3: Loading a different Module depending on the Configuration Download Code

Replies are listed 'Best First'.
Re: Re (tilly) 3: Loading a different Module depending on the Configuration by runrig (Abbot) on Sep 27, 2001 at 09:58 UTC
For one thing I would now demand that it loads the child class. Which means that either ... or you have to write dynamic loading logic. 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...	[reply]

Replies are listed 'Best First'.

Re: Re (tilly) 3: Loading a different Module depending on the Configuration
by runrig (Abbot) on Sep 27, 2001 at 09:58 UTC

For one thing I would now demand that it loads the child class. Which means that either ... or you have to write dynamic loading logic.

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...

[reply]