Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

What are the advantages or disadvantages of "require" over "use"

by ghosh123 (Monk)
on Apr 18, 2014 at 05:57 UTC ( #1082714=perlquestion: print w/ replies, xml ) Need Help??
ghosh123 has asked for the wisdom of the Perl Monks concerning the following question:

Hi ,
I just wanted to know about the advantages and disadvantages of "require" over "use" in Perl.

I know that :
1. "use" is evaluated at compile time and "require" at run-time.
2. If the module I am using with "use" has syntax error they will be thrown while compiling, on the contrary if the module is "require" ed then they will come during run-time and no errors will be reported in compile time.
3. When we do "use", the control is passed to that file at run-time and whereas in case of "require" the code from that module/file is included to my code which is "require"ing it at run-time.
4. If I have a module which does a lot in the BEGIN block and I don't really need it in all cases , then it is clever to "require" it so that I won't have to wait for all the initializations of that module in case I don't need it.

My question is :
is there any gain in terms of memory consumption when I use "require" or any other advantage ? Please let me know.
Thanks.

Comment on What are the advantages or disadvantages of "require" over "use"
Re: What are the advantages or disadvantages of "require" over "use"
by FloydATC (Chaplain) on Apr 18, 2014 at 06:31 UTC

    The most important difference between require and use when importing them is namespace control.

    Prior to Perl 5 you would require libraries to import everything into your script's namespace. Libraries would then potentially clash with both your own variables/subs and those of other libraries. Those libraries would typically have the extension .pl

    In Perl 5 this was solved by adding namespaces that spring into existence whenever referenced, and modules imported by use are by definition packages that have their own namespace. Only by explicitly exporting stuff into your main namespace can they cause problems. Modules to be imported with use must have the extension .pm.

    Well-written modules let you control what gets exported like this, for example this would ask the Foo plugin to put "bar" and "baz" (and nothing else thank you) into your main namespace:

    use Foo qw( bar baz );

    Another thing you will often see is modules offering a set of definitions as a group, those group names typically begin with a :colon. This reads as "give me everything needed for using that feature". But nothing else, please.

    Ofcourse, badly written modules exist, this is more of a guideline than a strict rule.

    Because namespaces matter so much, you're really not supposed to decide yourself how to import stuff written by others. Just as you can use a flathead screwdriver on a philips head, there are always ways to make a module work using require (and with some hacking, vice versa) but it doesn't make you look very professional and you will end up breaking stuff in the long run.

    -- FloydATC

    Time flies when you don't know what you're doing

Re: What are the advantages or disadvantages of "require" over "use"
by Anonymous Monk on Apr 18, 2014 at 06:41 UTC

    I just wanted to know about the advantages and disadvantages of "require" over "use" in Perl.

    There are none, use use, use is require :)

    I know that : list of things I kinda know

    :D

    is there any gain in terms of memory consumption when I use "require" or any other advantage ? Please let me know.

    use is implemented using require ... they're one and the same

    There are no gains in terms of anything ... its the same code

    Difference between 'use' and 'require', Re^3: Moo error message not understood (begincheck.pl)

Re: What are the advantages or disadvantages of "require" over "use"
by 2teez (Priest) on Apr 18, 2014 at 06:43 UTC

    Have you also seen or read these require and use

    If you tell me, I'll forget.
    If you show me, I'll remember.
    if you involve me, I'll understand.
    --- Author unknown to me
Re: What are the advantages or disadvantages of "require" over "use"
by kcott (Abbot) on Apr 18, 2014 at 07:19 UTC

    G'day ghosh123,

    In the use documentation, you'll see:

    It is exactly equivalent to

    BEGIN { require Module; Module->import( LIST ); }

    except that Module must be a bareword. The importation can be made conditional by using the if module.

    So, if you had to use require, you could still get the compile time checks with:

    BEGIN { require Module; }

    However, reading a bit further down the use documentation, you'll see that this is exactly equivalent to

    use Module ();

    So, unless you're unable to specify a bareword for Module (see this post of mine from a few days ago for an example), or you have a particular need to load Module at runtime (e.g. your point #4 scenario [although see below]), there's really no reason not to use use.

    Finally, regarding the points you made:

    1. Correct.
    2. Correct.
    3. The "control is passed to that file at run-time" part doesn't sound right at all. If, after reading the documentation I've provided links to, you still believe this is correct, please clarify what you mean (perhaps I'm missing your intent).
    4. In that particular scenario, you'd probably need to weigh up whether you want to avoid an initialisation delay at the expense of (conditionally) having the same delay at some point in the middle of the program. There are situations where modules are loaded conditionally, using require, that have nothing to do with initialisation delays (as an example, see the File::Spec source code).

    -- Ken

Re: What are the advantages or disadvantages of "require" over "use"
by tobyink (Abbot) on Apr 18, 2014 at 07:32 UTC

    If a module has a compile-time effect (exporters and pragmata), then use use. Otherwise (e.g. for OO modules), you can choose.

    A good reason to go with require would be when loading a module that isn't always needed. Say you are writing a module that offers load_from_file and load_from_web functions. In this case you might want to require LWP::UserAgent (or HTTP::Tiny or whatever) inside the definition of load_from_web. That way, if the person using your module never needs to load anything from the web (they only ever load from files), they can avoid loading LWP::UserAgent at all.

    use Moops; class Cow :rw { has name => (default => 'Ermintrude') }; say Cow->new->name
Re: What are the advantages or disadvantages of "require" over "use"
by sundialsvc4 (Abbot) on Apr 18, 2014 at 12:49 UTC

    Another thing which I consider to be quite important is that the use dependencies will be resolved as the software loads.   They will be static and unchanging throughout the lifespan of the process.   This is not true of require, which happens only when (and if) the statement is executed at runtime.

    Therefore, I suggest that you use require (by means of UNIVERSAL::require) only when it is clearly called-for.   And, one fine example of where it is called-for can be found in, say, an RPC server such as RPC::Any, or some large web-site servers where some components are far more commonly used than others.   In these cases, it might be desirable and appropriate to “demand-load” portions of the software at runtime.

Re: What are the advantages or disadvantages of "require" over "use"
by rnewsham (Hermit) on Apr 18, 2014 at 15:37 UTC

    I see you have also posted this question on linkedin. Which is not a problem but it is considered polite to mention it here to avoid anyone wasting their time giving duplicate information.

Re: What are the advantages or disadvantages of "require" over "use"
by Your Mother (Canon) on Apr 18, 2014 at 17:54 UTC

    What tobyink said. An example where I always choose require and put it in subs/methods is the admin functions in webapps. Most of an applicationís users canít even see the admin code so there is no point in taking the hit on all requests. Plus you can be less worried about bringing in many/heavy/slow modulesĖ

    use AllUserStuff; sub admin_stuff { require HugeExpensiveCodeRarelyEverCalled; require ManyMoreOtheSame; ... }

    Just make sure to write good tests around it so you donít get the run time surprises you mentioned.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1082714]
Approved by rnewsham
Front-paged by kcott
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (16)
As of 2014-12-18 14:34 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (55 votes), past polls