Re: module problems

You can also do use my_mod qw(cat) ... in other words, declaring the names from my_mod that you wish to, well, “import from” it.

Two ways ... export or import ... same cat. (meow...)

And actually, I find that the explicit use of name-space references (e.g. my_mod::cat) can actually be quite useful, since it explicitly declares where the names are expected to come from. Anyone who's looking at the code can tell at a glance, not only “where to look,” but also “the one-and-only place where the computer will be looking.” (purrr....)

Consider: when you use a library that exports a whole lot of things, it could be argued that you run the risk of “polluting your namespace” with a bunch of exported routines that you don't need... and that you were not explicitly aware of. This can be the source of much grief, with the commensurate abuse of available hair-follicles.

Certainly one of the most annoying and time-wasting (hence, expensive!) sources of bugs are those where you thought you knew how the computer was interpreting a particular line of source-code, but you actually didn't. That's one reason why I rather prefer the “imports” approach rather than “exports.” It allows you to understand the behavior and the proper reading of a particular package fully when looking only at that package. To me, that's a very desirable characteristic for source-code to have.

I don't make such an observation “dogmatically,” of course. Very few things in this business are truly dogmatic. But I do observe it to be characteristically useful.

Replies are listed 'Best First'.
Re^2: module problems by blazar (Canon) on Apr 03, 2008 at 15:53 UTC
You can also do `use my_mod qw(cat)` ... in other words, declaring the names from `my_mod` that you wish to, well, “import from” it. I personally believe you missed something very important: what you suggest will only work if `my_mod` uses Exporter (or otherwise reimplements its functionality, to be really anal) to include `cat` in the list of symbols allowed to be exported, through `@EXPORT_OK`. Simply doing what you suggest will only cause the `use` statement to call `my_mod->import('cat')`. But the `import` method must be implemented, and `Exporter` provides a "standard", flexible way to do so. PS: why are you using `<tt>` tags? Code tags should be the preferred way to refer to code, be it a single name, in PM. And `<c>` is even easier to type, than `<tt>`. `--` If you can't understand the incipit, then please check the IPB Campaign.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: module problems
by blazar (Canon) on Apr 03, 2008 at 15:53 UTC

You can also do use my_mod qw(cat) ... in other words, declaring the names from my_mod that you wish to, well, “import from” it.

I personally believe you missed something very important: what you suggest will only work if my_mod uses Exporter (or otherwise reimplements its functionality, to be really anal) to include cat in the list of symbols allowed to be exported, through @EXPORT_OK.

Simply doing what you suggest will only cause the use statement to call my_mod->import('cat'). But the import method must be implemented, and Exporter provides a "standard", flexible way to do so.

PS: why are you using <tt> tags? Code tags should be the preferred way to refer to code, be it a single name, in PM. And <c> is even easier to type, than <tt>.

--
If you can't understand the incipit, then please check the IPB Campaign.

[reply]
[d/l]
[select]