Re: package splitting and 'our' use

Having MyConfig.pm mock with MyPackage is probably better done by using

    use MyPackage qw(:sometag);
[download]

and have MyPackage's import() function deal with it and do something meaningful with it.

Comment on Re: package splitting and 'our' use Select or Download Code

Replies are listed 'Best First'.
Re^2: package splitting and 'our' use by steves (Curate) on May 10, 2005 at 04:28 UTC
This approach forces the preliminary "bootstrap" configuration package to include modules that depend on it. Suppose, for example, that part of the configuration set up is to use different package @INC paths to pull in different code trees based on environment (development versus production, etc.). Having to use the packages the configuration is trying to affect means that they may get pulled in too soon, rendering the configuration piece useless for those packages. It's your classic chicken/egg problem. My goal is to write these configuration pieces so they're as independent of the rest of the code as possible, thereby allowing them to set things up that affect the rest of the run-time environment without having to hook into those run-time packages too deeply. They're very much like shell level environment settings in that regard.	[reply]

Replies are listed 'Best First'.

Re^2: package splitting and 'our' use
by steves (Curate) on May 10, 2005 at 04:28 UTC

This approach forces the preliminary "bootstrap" configuration package to include modules that depend on it. Suppose, for example, that part of the configuration set up is to use different package @INC paths to pull in different code trees based on environment (development versus production, etc.). Having to use the packages the configuration is trying to affect means that they may get pulled in too soon, rendering the configuration piece useless for those packages. It's your classic chicken/egg problem. My goal is to write these configuration pieces so they're as independent of the rest of the code as possible, thereby allowing them to set things up that affect the rest of the run-time environment without having to hook into those run-time packages too deeply. They're very much like shell level environment settings in that regard.

[reply]