Re: Why is @flds not imported?

[ikegami]

You gotta be super careful when you place a module in a script or in the same file as another module. It's very easy to execute code in the wrong order. And this is what happened here.

Let's look at the following simplified version of your code:

{
  package Fields;
  our (@flds, @EXPORT);
  @EXPORT=qw(@flds);
  use Exporter 'import';
}

package main;
use Fields;
my $nfld = scalar @flds;

In broad strokes, the following is the compilation and execution process:

1. Script's compilation phase:
   1. our (@flds, @EXPORT) is compiled.
   2. @EXPORT=qw(@flds) is compiled.
   3. use Exporter 'import'; is compiled:
      1. require Exporter; is executed:
         1. [Exporter.pm's compilation phase happens here]
         2. [Exporter.pm's runtime phase happens here]
      2. import Exporter 'import'; is executed.
   4. use Fields; is compiled:
      1. require Fields; is executed.
      2. ⇒ import Fields; is executed. ⇐
   5. my $nfld = scalar @flds; is compiled.
2. Script's runtime phase:
   1. our (@flds, @EXPORT) is executed.
   2. ⇒ @EXPORT=qw(@flds) is executed. ⇐
   3. my $nfld = scalar @flds; is executed.

Note the relative order of the statements in bold. At the time of import, @EXPORT was empty.

Fix:

BEGIN {
   package Fields;
   use strict; use warnings;
   use mem;
   our (@flds, @EXPORT);
   @EXPORT=qw(@flds);
   use Exporter 'import';
   $INC{"Fields.pm"} = 1;
}

{                    # <-- Not necessary, but enforces cleaner code.
   use strict; use warnings;
   use Fields;
   my $nfld = scalar @flds;
}

[LanX]

What really puzzled me, is why the require in use Fields is not throwing an error.

And changing the name did indeed show a conflict. Turns out that the pragma fields (lowercase) comes with a bundled "class" (or whatever) Fields (capitalized) which is used.

C:\Windows\system32>corelist fields

Data for 2013-01-20
fields was first released with perl 5.005

C:\Windows\system32>perldoc Fields
NAME
    fields - compile-time class fields

SYNOPSIS
...

[perl-diddler]

Why should 'use Fields' throw an error? It's included in the file.

The copy of Fields in memory will have priority over the disk version with 'use mem'.

Edit: Oh -- you are not talking about my version... nevermind.

[LanX]

> Why should use Fields throw an error? It's included in the file.

but not in %INC

See require and perlvar#%25INC :

> The hash %INC contains entries for each filename included via the do, require, or use operators. The key is the filename you specified (with module names converted to pathnames), and the value is the location of the file found. The require operator uses this hash to determine whether a particular file has already been included.

[perl-diddler]

You gotta be super careful when you place a module in a script or in the same file as another module. It's very easy to execute code in the wrong order. And this is what happened here.

Unfortunately, it's not an 'order' thing as it's not the problem anon-monk suggested it was. :-(

I trimmed away too much for the "simplified case" and didn't notice when I oversimplified it because it gave the same error message (even when I had code in the BEGIN phase). *sigh*

So it's back to the drawing board.

Edit Didn't have to go far...seems to have something to do with whether or not another package using the same module (Fields) is present AND my own export routine. I suspected it was in my own export code, but when I substituted the standard Exporter I got the same error -- but only because I'd already removed the 'BEGIN' code.

If you're interested, when I figure out the problem, I can update things here, but it's likely some boring error where I missed something simple. ;-)

-l

[LanX]

All this smells like an XY Problem.

What is your real goal?

[perl-diddler]

??? I don't think so. No more than any attempt to distill a minimal test case from some original source file is.

Arriving at a distilled test case that presents the same diagnostic but isn't really the same problem is a hazard of desiring a distilled test case.