On 3/13/22 13:13, David Christensen wrote:
> I have been wrestling with the Exporter module and subroutine circular
> dependencies between modules for a number of years.
https://www.mail-archive.com/module-authors@perl.org/msg10914.html
We revisited this topic at a San Francisco Perl Mongers me
On 3/13/22 16:12, Shawn H Corey wrote:
Each module has its own runtime. That is, a module is loaded, compiled
and run; all before the main program. In other words, when the module
returns from its `use` statement, it has already run.
AIUI that is the view from 20,000 ft.. But, there are det
On 3/13/22 15:44, Diab Jerius wrote:
On Sun, Mar 13, 2022, 18:19 Shawn H Corey wrote:
use Exporter qw( import );
our @EXPORT = qw( foo );
our @EXPORT_OK = qw( );
our %EXPORT_TAGS = (
all => [ @EXPORT, @EXPORT_OK ],
);
This automatically creates a tag for `:all`.
I prefer
On 3/13/22 15:18, Shawn H Corey wrote:
On 2022-03-13 18:08, Diab Jerius via module-authors wrote:
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( foo )
I prefer this way:
# --
# Exports
use Exporter qw( import );
our
On 3/13/22 15:08, Diab Jerius via module-authors wrote:
On 3/13/22 16:13, David Christensen wrote:
module-authors:
I have been wrestling with the Exporter module and subroutine circular
dependencies between modules for a number of years. I have yet to
find a satisfactory solution.
If you m
On Sun, Mar 13, 2022 at 1:14 PM David Christensen
wrote:
module-authors:
I have been wrestling with the Exporter module and subroutine circular
dependencies between modules for a number of years. I have yet to find
On 3/13/22 14:57, Karen Etheridge wrote:
> I haven't looked at your code, b
On 3/13/22 19:12, Shawn H Corey wrote:
On 2022-03-13 18:44, Diab Jerius wrote:
I prefer yet another fashion (everything is driven by what's in
%EXPORT_TAGS), but back to the point of the OP's problem, this
doesn't initialize @EXPORT until runtime, so I think will have the
same issue (I'm a
On 2022-03-13 18:44, Diab Jerius wrote:
I prefer yet another fashion (everything is driven by what's in
%EXPORT_TAGS), but back to the point of the OP's problem, this doesn't
initialize @EXPORT until runtime, so I think will have the same issue
(I'm away from keyboard at the moment).
Each
On Sun, Mar 13, 2022, 18:19 Shawn H Corey wrote:
> On 2022-03-13 18:08, Diab Jerius via module-authors wrote:
>
> require Exporter;
> our @ISA= qw( Exporter );
> our @EXPORT= qw( foo )
>
> I prefer this way:
>
> # --
> # Exports
> use Exporter qw(
On 2022-03-13 18:08, Diab Jerius via module-authors wrote:
require Exporter;
our @ISA = qw( Exporter );
our @EXPORT = qw( foo )
I prefer this way:
# --
# Exports
use Exporter qw( import );
our @EXPORT = qw( foo );
our @EXPORT_OK
On 3/13/22 16:13, David Christensen wrote:
module-authors:
I have been wrestling with the Exporter module and subroutine circular
dependencies between modules for a number of years. I have yet to
find a satisfactory solution.
[...]
What is the "proper" way to avoid or solve the problem o
I haven't looked at your code, but I assume what you're doing is exporting
a sub from each module, and something in each of those modules is calling
each of those subs in turn, using the exported symbol. This is indeed an
unresolvable circular dependency because unqualified sub names must be
resolv
module-authors:
I have been wrestling with the Exporter module and subroutine circular
dependencies between modules for a number of years. I have yet to find
a satisfactory solution.
To explain the problem: assume I have a module Foo that contains a
subroutine foo(), a module Bar that cont
13 matches
Mail list logo
