Toolkit is a fantastic idea, but soffer a one limitation.
use Toolkit qw(::xxx::yyy);
in this mode not search the toolkit files in directory $PERL5LIB/Toolkit
but in directory $PERL5LIB/xxx/yyy/Toolkit
In this way does not pollute external namespace, useful for modules in cpan
Was this review helpful to you? Yes No
Toolkit is exactly what we needed for our project. Aside from the obvious advantages listed in the module's documentation, when you have several developers working on the same system, adding and modifying packages, it is a tremendous aid to promoting standards (and reducing clutter in scripts).
5 out of 6 found this review helpful. Was this review helpful to you? Yes No
Toolkit lets you save typing or cut/paste by saying "use Toolkit" instead of "use strict; use warnings; use Acme::Whatever" and whatever other favorite modules you like to use all of the time.
It's a really neat idea. It is also a really bad idea.
It saves keystrokes. But the script or module ceases to be portable to another machine (let alone another OS), and the code is less self-documenting as to what modules it uses.
There's no tool to modify a script or module to insert the used modules in place of "use Toolkit", should one desire to see what's being used.
However, I can see cases where this would be useful: if someone has a large stock of standard modules to always be used.
I think it would be better to have some kind of "profile" configuration file that lists modules used (using "use", "no" or "require"). One could dump the module, or updated versions of Module::Build or ExtUtils::MakeMaker could include the profile file with a distribution, etc.
9 out of 10 found this review helpful. Was this review helpful to you? Yes No
1 hidden unhelpful review