in reply to Re: Bundling commonly-used modules into a toolset
in thread Bundling commonly-used modules into a toolset

Cool. That's one of the applications for which I thought it might be useful. I don't think that use base will work because it doesn't call import. You could do it in two steps, though: 

package Restaurant::People::Cook;

use Restaurant::People; # A ToolSet module
our @ISA = qw( Restaurant::People );

[download]

I suppose I could add a method to ToolSet that adds the ToolSet module to the caller's @ISA. Then you'd get the imports and set up a subclass.

ToolSet->set_base(1);

[download]

The other approach would be to explicitly set base modules, so it doesn't necessarily have to be the ToolSet module: 

ToolSet->set_base('Restaurant::People');

[download]

Any preference?

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^3: Bundling commonly-used modules into a toolset
by creamygoodness (Curate) on Oct 28, 2005 at 17:55 UTC
    After some experimentation, I've concluded that it's a good thing that use base and use My::ToolSet require separate lines -- because of what other people will expect when they subclass.

    If someone writes this: 

    package BunnyBurgers::PRFlack;
use base qw( Restaurant::People );

    [download]

    ... they won't be expecting to have have a whole bunch of extra functions pulled into their namespace, or changes in pragma behavior. Now it's true that all of a sudden all of the imports I brought in via Restaurant::Util::ToolSet to Restaurant::People are available as methods, so $pr_flack->can('dualvar'). But that happens anyway -- $nearly_any_object->can('carp') -- and at least subclassers don't have to worry about surprise namespace polution in their actual module code.

    For the time being, I've settled on starting all the modules like this: 

    package Restaurant::People::Cook;
use Restaurant::Util::Toolset;
use base qw( Restaurant::People );

    [download]

    There will only be one ToolSet in the entire distro, and it will bring in strict, warnings, Carp, Scalar::Util, and a global RESTAURANT_DEBUG constant. Restaurant::Util::Toolset class won't be public, so it will be possible to modify it, but I'm expecting to keep it stable. That should cause minimum confusion. The only people who need to know what's in Restaurant::Util::Toolset are people who are hacking/debugging modules which use it.

    So, to answer your question, I wouldn't really use either one of those. Multiple inheritance of ToolSet-enabled modules would just get too messy.

    I'm quite happy with what we've got now. By compressing several lines at the top of the file into one, a bunch of meaningful, frequently edited code now appears in the the first screenful, so when I type "gg" in vim, I'm right in the game.

    --
    Marvin Humphrey
    Rectangular Research ― http://www.rectangular.com
[reply]
[d/l]
[select]

In Section Meditations