After writing the first version of Exporter::VA, I asked "now what", meaning how do I promote it and get it out there.

Well, I realized that I really need acceptance rather than awareness. CPAN and discussions take care of the latter. So, since this is supposed to do everything Exporter does as just a jumping off point, then add new features, my idea was to provide an automatic translation tool.

So, I wrote Exporter-VA-Convert (see docs here, last time I tried to paste the generated HTML into a perlmonks node it didn't quite work out right). This loads the module and then examines the resulting package globals that Exporter::import uses. It can't really rewrite the source code because it never directly parsed it. It only cares about the resulting value, not how it was computed, so just loading and letting the module's logic take care of itself seems like a great thing to do. But, instead of changing the code, it tells you what definitions to change, delete, and insert.

This generates a Exporter::VA export definition with the same meaning, including default exports, OK exports, and taglists. It also sets up callbacks and gives you the skelleton for the sub (though it can't write it for you) if it detects @Exporter::EXPORT_FAIL. It also checks to make sure the module is using Exporter in the normal way in the first place, detecting custom imports and other funny things.

It was very interesting to write this kind of introspective code. It resulted in a few questions to this forum, too, including the code ref issues and digging into Data::Dumper.

Now this conversion utility just makes an exact conversion with the same meaning. The next step is to offer some switches to change that, since the whole point of "upgrading" to Exporter::VA is to take advantage of its particular features. In particular, getting rid of default exports while retaining backward compatibility. So I think I'll have a switch to generate separate old and new default export lists with the new being empty, and then you can edit that, pasting in stuff copied from the old one if you don't plan to get rid of all of them. Perhaps the switch should let you specify any tags you want versioned.

On a more cosmetic note, I'd love to have a more compact qw/ ... / output instead of the fully quoted, one word per line generated by Data::Dumper.

Well, what do y'all think of these ideas?

—John

In reply to My module - my latest step by John M. Dlugosz

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.