Perl: the Markov chain saw | |
PerlMonks |
Re^3: Bundling commonly-used modules into a toolsetby creamygoodness (Curate) |
on Oct 28, 2005 at 17:55 UTC ( [id://503722]=note: print w/replies, xml ) | Need Help?? |
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:
... 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:
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.
In Section
Meditations
|
|