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

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.

Replies are listed 'Best First'.
Re^4: "use" modifier code via import()
by tye (Sage) on May 18, 2004 at 02:04 UTC

    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]

        Personally, I hate Exporter: in general, I don't want anyone stomping on my namespace, and I'm happy to fully qualify function calls and variable references (indeed, eager to, since it makes the code far clearer).

        To me, import() is about bringing in the requested functionality: typically, modifying the behaviour of the package I'm loading as a result of the arguments I supply to use. Any and all creative use of import() (properly documented, of course) is fine by me.

        Hugo

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom