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

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.

  • Comment on Re: Re: Re: import() not getting called. Huh?

Replies are listed 'Best First'.
Re: Re: Re: Re: import() not getting called. Huh?
by John M. Dlugosz (Monsignor) on Dec 21, 2002 at 07:23 UTC
    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]

      The method used by such people as Tom Christiansen to avoid importing names by default, is to avoid use of the default export mechanism altogether. Import the names you need, or else live with the chance that too many names are imported.

      Re: inlined comments do not describe code flow, I mean that the comments do not provide me additional insight into understanding the code flow. It may be that adjusting the indenting scheme to use a more common strategy would drastically reduce the apparent complexity. My opinion is only based on the fact that I am accustomed to reading code, and I could not easily follow your code. This may mean that your code is too advanced for me, or it may mean that your code is difficult to read. Take it how you wish. I tried to find your problem, and I became lost.

[reply]
        I still don't know what you mean by "code flow". if statements, while statements, etc. mean what they mean and don't need further explaination except to the youngest novice: we know how program execution "flows".

        My indenting is 3 spaces per level, which I think is a median value (2 to 4 is common, 8 rare but sometimes seen), and subordinate stuff is indented relative to the controlling line, which is also normal enough. So I don't know what you find "extremely odd".

        I do find that it's easy to become lost, and I think that's because of the meta-ness involved. That is, function there actually generate the functions that are then called. And, the same mechanism that generates the export for the Module is the one that the Module subsequently uses to export its stuff to the Client, so thinking about "the module", "the symbol", etc. makes one forget which role one is in. I'm trying to overcome that by careful and consistent nominclature.

        —John

[reply]

In Section Seekers of Perl Wisdom