in reply to Re^4: What's so wrong with this (dereferencing)code?
in thread What's so wrong with this (dereferencing)code?

> in an unrelated module you'll be able call POSIX::strftime anywhere else in your program

That's correct and consistent for any required module, because you use a full qualified path to the function which was loaded.

I'd call this bad style in the case of a general module like POSIX though, because there is no harm in explicitly reloading it again if needed in the current module. It's an NO-OP if it's already loaded, and essential if not.

There are groups of modules/classes which are so deeply intertwined that it's not only OK but explicitly documented in the main module, to make calls to dependencies.

The magic word here is explicit

Cheers Rolf
(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery

Replies are listed 'Best First'.
Re^6: What's so wrong with this (dereferencing)code?
by cavac (Prior) on Jun 27, 2024 at 11:44 UTC

    As purely a side note:

    I stuffed a lot of date/time/datetime/timestamp code i use into wrappers in a central module of my framework. It's not the best for performance, but it helps during testing. It's quite astonishing for how much timestamp based crap you have to test in commercial 24/7 applications, including leap years, DST changes etc.

    And plainly wrong system times, because some clueless admin didn't understand NTP and firewalled it. And just playing with the system time isn't enough, because the database server in production might have a different time than the application server. During dev, everything runs on a single laptop, so i need a single place where i can fudge the time functions in Perl, so i can test if i accidently mix local and remote timestamps...

      I think you are referring to loading a bunch of modules at once to avoid boilerplating.

      Again, that's ok as long as it's explicitly documented.

      And normally it's only a "dependency of second degree", looking into the container module will directly reveal the target modules. And (hopefully) the container will have a clear name.

      I've seen some counterexamples in my work life with "try and error" code which was considered "working" because it didn't fail at time of coding.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      see Wikisyntax for the Monastery