in reply to USE or Require?

False dilemma.

use happens at compile-time while require happens at run-time. There's a big difference. You can also control what's imported into your namespace by providing arguments to use — besides that, there's no reason import() has to export anything. Several modules use different behavior based on what you pass to import(), and if you only use your "precise" require, you'll miss out.

Replies are listed 'Best First'.
Re: Re: USE or Require?
by diotalevi (Canon) on Jul 22, 2003 at 22:54 UTC

    Also, if the module requires actions at CHECK or INIT time you've just cut that functionality out - runtime happens after INIT and CHECK so whatever initialization the module was expecting will never occur. That's a good reason to use 'use()' right there.

[reply]
Re: Re: USE or Require?
by BUU (Prior) on Jul 23, 2003 at 02:23 UTC
    Sigh. Perhaps I chose terms that were too specific for the attitudes I was trying to convey. You certainly choose to debate the merits of the specifics rather then the nature of the general.

    My main point was not to nit pick the differences between use and require, but rather to look at the question of "Is it false lazyness to import subroutines/vars/etc into your namespace?". It's lazy in a good way because you don't have to type endless amounts of semicolons, but then it's lazy in a bad way because you don't know exactly where the subroutine came from. Obviously I favor the latter arguement, that "Foo::Baz()" is preferable to "Baz()" due to it's self documenting nature, it lets you know exactly where the subroutine is coming from and what it corresponds to.
[reply]

      Okay, that's a different question and worth more thought.

      I don't have a problem importing things into my namespace for three reasons:

      • I keep my code fairly short, so I don't have to import many things.
      • I tend to import only the things I really want, so the use line explicitly says what I want.
      • When I bend my second point, I only do so with well-defined idioms, such as with the Test::* modules or something like File::Path.

      I expect someone maintaining my code to be able to find the original location of functions I've imported. I try not to make it hard on that person, but I don't believe in writing un-idiomatic code because it's perceptually "self-documenting". Part of maintainability is readability and duplicate code hurts that.

[reply]
[d/l]

      I'll second chromatic and add:

      • If you ever feel like getting a drop-in replacement you'd need to do dangerous things.

      I generally dislike hardcoded things, and using a fully qualified name is no exception.

      ihb

[reply]
[d/l]

      I think using require is false lazyness. And the points that were made about require are very valid and pertinent to the discussion of using one over the other. IMO its use unless you have _very_ good reason to want to use require. And one of those points that is sofar unmentioned (I think) is that prototypes arent respected by code that is 'required'.


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
[reply]
[d/l]
[select]

In Section Meditations