in reply to import() not getting called. Huh?

I spent a good 20 minutes looking at your code (1490 lines of code!). It is excessively complicated for the task that it seems to be accomplishing. Without verifying every line of code, the only thing I can suggest at this point is:

  1. Re-write the code to be easier to read, and much simpler. In particular, the interface should be simpler.
  2. If I had to make a bet, I would say that a global variable, or lexical variable within a closure, is being used or defined incorrectly.

Sorry I cannot be of more help.

Replies are listed 'Best First'.
Re: Re: import() not getting called. Huh?
by djantzen (Priest) on Dec 20, 2002 at 05:50 UTC

    I've just spent a nice chunk of time looking over this too, and the only interesting result I got was after useing only M1 and M3 the error: NOT IMPLEMENTED YET. at test1.perl line 60 BEGIN failed--compilation aborted at test1.perl line 60. (The line is use M3 ..., in case our line numbers are off.) It appears to be upset at foo, and aborting compilation. What we really need is to step through the BEGIN blocks with the debugger, but I don't even think that's possible. Hopefully that's a helpful clue, John; it's the best I can do.

[reply]
[d/l]
[select]
      That's what's supposed to happen when M3 is used, since it's not implemented yet. I wrote the test code before continuing, so I can test as I go. And found that it's not being tripped if M2 is used both before and after.
[reply]
Re: Re: import() not getting called. Huh?
by John M. Dlugosz (Monsignor) on Dec 21, 2002 at 05:18 UTC
    I think you're counting the documentation lines, not the code. The module (with internal comments but not the manual in the attached POD) is under 400 lines.

    I'm sorry you find it excessively complicated. I thought it was elegant and to the point for the task it is documented as accomplishing.

    The interface has been well-received, in fact. See the replies to the original design draft at Module Design strawman - Exporter::VA. If you have any serious suggestions to improve it, I'm all ears.

    —John

[reply]

      I'm counting lines of *.pm and *.perl. I think the problem I have with your code is that it is very difficult to read. The indenting scheme is extremely odd, and inlined comments do not describe the code flow.

      To me, the idea of modules having fine-grained interface versioning, while cute, is heavy-weight. I prefer simpler modules that provide backwards compatible methods, or are renamed when the functionality or interface is changed substantially enough to require a new interface. The potential for a single module to provide 50 different interfaces to its caller, depending on how it is included, presents a regression testing nightmare in my books.

      If the interface needs to change substantially enough that compatibility methods are insufficient, either the module was not designed properly in the first place, or the module deserves a new name. In either case, the various intermediate interfaces should be obsoleted as soon as possible to prevent confusion.

[reply]
        My motivation is to be able to remove default exports in updated modules. True, changing the functionality can be handled by changing the name, but I want to be able to clean up modules that export by default.

        Re: inlined comments do not describe the code flow, can you be more specific?

        —John

[reply]

In Section Seekers of Perl Wisdom