in reply to Re: "use" modifier code via import()
in thread "use" modifier code via import()

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.

Replies are listed 'Best First'.
Re: Re: Re: "use" modifier code via import()
by tilly (Archbishop) on May 18, 2004 at 00:37 UTC
    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]
Re: Re: Re: "use" modifier code via import()
by perrin (Chancellor) on May 18, 2004 at 01:10 UTC
    It's easy to set a one-time value without polluting the namespace:
    
use Test::More;
Test::More::plan( tests => 3 );

    [download]
    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).

      - tye        

[reply]
        Well, strict, warnings, and lib are all pragmas, so I don't expect them to behave the same as user-written modules. CGI mostly uses the import parameters for importing. The "pragmas" it provides could be handled in another way. The CGI interface is pretty strange, and I wouldn't hold it up as an example of something I would want others to follow.

        I've certainly never read that rule anywhere and don't assume only symbol exporting when I see a module.

        There are no rules, as we all know, but some things are more confusing than others. Sometimes people go overboard with Perl's flexibility in order to get a certain syntax that appeals to them. The core documentation on the creation of modules is nearly all about using Exporter, and the idea that a function called "import" would be doing something entirely unlike importing is not obvious to people who haven't seen it done before.

[reply]

In Section Seekers of Perl Wisdom