OOP and import()

Herkum has asked for the wisdom of the Perl Monks concerning the following question:

I have some OO modules that I need to be declared in a particular order and must ensure that code is called in parent modules before being called in the modules that inherit from it.

First is the basic Configuration module, it establishes a DBI connection so has to come first.

use My::Config 'test';

package My::Config;

sub import {
    my $package = shift;
    my $option  = shift;

    #initialize DB connection here
}
[download]

Next is my basic Object-Relational-Model code, it needs that DBI connection from the My::Config module to automatically run some code when it is initially used.

package My:ORM;

use base My::Config;

# Need to run My::Config::import()
# Need to run My::ORM::import() or something similiar
[download]

After 'using' the two previous modules, I want to run some more code in the Model.

package My::ORM::Model;

use base My::ORM;
[download]

I guess my question is, is import() being used in modules or is it like any other subroutine, I would have SUPER my way down the Config module to ensure that everything gets called in proper order?

OR? Is there another approach that I am missing that I should try? When these modules are use'd I only need the code to be run once; (for example, I don't constantly need to create a DBI connection once I have one.

Comment on OOP and import() Select or Download Code

Replies are listed 'Best First'.
Re: OOP and import() by Joost (Canon) on Dec 10, 2007 at 20:59 UTC
as far as I know base does not (in general/reliably) call import(). While a `use SomeClass;` will always call `SomeClass->import()` which is then resolved using the regular inheritance mechanism (which is how Exporter works, for example) i.e. - if SomeClass::import is there, it call that, otherwise it works itself up the inheritance (@ISA) tree for SomeClass. update: note that if you need your code in SomeClass to run only once per process (instead of once per `use`) you can just put that code outside of any subroutine in SomeClass.pm and it will get run the first time that module is require()d or use()d. See also use and require. update 2 there is no modeling reason any of your modules should inherit from the configuration at all. I would go as far as to say that that would be a badly implemented model. (though you could make the case that it should inherit from a base that has access to the configuration). See also my reply to Sharing data between children modules. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply] [d/l] [select]
Re: OOP and import() by fmerges (Chaplain) on Dec 10, 2007 at 22:35 UTC
Hi, Besides was Joost said so far... Personally I don't like the fact of having a Config class that connects to a database and created a database handler... and even not talking about relying on some "magic" like the fact that use calls import while base does not... Don't you think something is wrong in the design itself? Why you don't have a Config class just for config purposes? Even the connection to the database can be in his own class or even in a base class for your model, so that it gets called via super... there are a few alternatives, but I really would leave Config for configuration, right now you think about connecting from it to a database, but it might be that later on, you think that it could be handy to _not_ connect to a database... Resuming, think again about what you want to achieve, is there really any constraints of doing it the way you're thinking? Regards, fmerges at irc.freenode.net	[reply]


go ahead... be a heretic
	PerlMonks