I was intending to combine the use with the value override because I like the way that Test::More does this. In my opinion, it is a good place to set a one-time value, without polluting the namespace. It keeps the code compact from the user's perspective.
Regarding the import trick, I will ensure it is clearly- and well-documented. I didn't think of it as a trick, because I had seen it before in standard Perl distribution code, and considered it tacitly accepted by the community at a minimum, and familiar at least to those who write unit tests.
Thank you for responding. I respect your opinion.
| [reply]
[d/l]
[select] |
Setting a global variable from another module is also another dangerous practice. Sometimes it is useful, witness Test::More. However it is a fragility in the code. For instance if there is any possibility that your module can be used twice in the same code, with different defaults, you have no sane behaviour.
Therefore I'd advise you to think very carefully before creating APIs that set some global value, let alone trying to make it easy in your API to do that. There are times when it is clearly so unlikely to cause problems that nobody could reasonably object. But those occasions are few and far between. Test::More should be viewed as far more of the exception than the rule in this respect.
| [reply] |
It's easy to set a one-time value without polluting the namespace:
use Test::More;
Test::More::plan( tests => 3 );
This code does the same thing, but has no tricks that will make someone trying to maintain it scratch their head. To each their own, but I wouldn't want anyone using sneaky import() tricks in code that I would be responsible for maintaining some day. | [reply]
[d/l] |
I guess you never use strict, warnings, lib, CGI, or many other core modules since it would be hopelessly confusing for people to find that they weren't importing symbols into your package.
I don't know where this 'use is only for importing symbols' meme snuck in, but I've certainly never read that rule anywhere and don't assume only symbol exporting when I see a module. In fact, the meme is plain wrong.
It is certainly common for modules to primarily export symbols. It is also certainly common for subroutines to work on numbers. But there are plenty of modules that don't export symbols and it often makes sense to make it easy for the module user to pass arguments in.
In fact, I'm pretty sure that Larry and company provided the mechanism for that reason, especially since they immediately went out and used it (and not for importing symbols).
| [reply] |