in reply to How to export several modules intu users name space to not have a use ...; use ...; use ...; with the same modules all over again

You could look at Toolkit, which purports to eliminate company-specific boilerplate.

Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

sitecustomize.pl is close, but it is run in its own scope so use strict; would not be enabled by this. Maybe consider adapting what common::sense does to your own needs? common::sense does its thing via XS, which is likely too unwieldly for your needs.

Modern::Perl does the following:

sub import { my ($class, $date) = @_; $date = $wanted_date unless defined $date; my $feature_tag = validate_date( $date ); undef $wanted_date; warnings->import; strict->import; feature->import( $feature_tag ); mro::set_mro( scalar caller(), 'c3' ); }

... and most likely, you could write Modern::Perl::MyCompany, which does the same, except with the modules you want, like by adding:

POSIX->import( 'strftime' );
  • Comment on Re: How to export several modules intu users name space to not have a use ...; use ...; use ...; with the same modules all over again
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: How to export several modules intu users name space to not have a use ...; use ...; use ...; with the same modules all over again
by bigj (Monk) on Jan 12, 2015 at 09:56 UTC
    Yep, Toolkit was the module I remembered. Thanks to pointing me to.

    Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

    Me not also, I want to have an easy way to write quick and dirty one liners or 4 liners for simple stuff :-) Firm policy is putting it inside as posted and for production code running at live systems, I'd enhance it also (allthough I need good examples of how much you can shorten source code to fight vs copy+paste culture :-))

    Greetings,
    Janek Schleicher

Re^2: How to export several modules intu users name space to not have a use ...; use ...; use ...; with the same modules all over again
by RonW (Parson) on Jan 12, 2015 at 19:30 UTC
    Personally, I'm not too happy with hiding "boilerplate" away, but if you have a strong company policy, using something like Toolkit might make it easier to do the right thing for everybody by implicitly loading the modules.

    Where I work, the company policy for C/C++ projects is to use #include "standard.h" where standard.h contains a series of #includes and definitions we are required to use. (We are allowed to modify the project specific standard.h to fit project needs.) The rational behind this is to provide a single file (in each project) for these items to be edited, thus reducing the opportunity for introducing inconsistencies and other errors into the code.

    Doing similar with Perl (and whatever other languages used in the company) would be consistent with the spirit of company policy for C/C++ projects. (All of the production software in our products is written in C/C++. For "in house" tools, the language used is left to the creator of the tool. Perl, LabView and CAPL are most common for engineering tools; VB macros for "office tools").