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

It is now the user's responsibility to use the right child module for what they are doing.

Unless, of course, the right module needs to be determined at run time :-)

Update: I guess sometimes its just preference between doing this:

my $package = "Parent::Package::".$subpackage;
$package->method;

# And this:
Parent::Package->method($subpackage);
[download]

I see the reasoning of doing it the first way, but sometimes I just prefer to do it the second way. I started allowing it with Parse::FixedLength, and I'm not the only one, as AnyData also does that. One of the wonders (or drawbacks, depending on who you ask) of Perl is that its only as OO as you want it to be :)

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

Replies are listed 'Best First'.
Re (tilly) 3: Loading a different Module depending on the Configuration by tilly (Archbishop) on Sep 26, 2001 at 22:29 UTC
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.	[reply] [d/l]
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]