in reply to Re: (bbfu) (Exporter::VA) Re: Exporter::Dream
in thread Exporter::Dream

In specific, Exporter::VA will do everything Exporter::Dream does, except for automaticly creating the :all tag. It also has the advantage of already exsiting, and doing pretty much anything you'd want an Exporter to do.

It's a huge exporter with lots of options, various prefixes and (imho) unclear syntax. Although it does indeed do much of what Exporter::Dream does, I think the two can happily live together (I hope ::VA will get something like _prefix too. It's trivial to implement, and makes things much nicer). I'm not after versioning or configuration through the import method, especially not with v-strings :).

You say Exporter::VA has the advantage of already existing. While that is true, it is of not much use until it is uploaded to CPAN. You used a cpan:// link, so you probably thought it was already there. Either it is not, or search.cpan.org is broken. 

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

  • Comment on Re: Re: (bbfu) (Exporter::VA) Re: Exporter::Dream

Replies are listed 'Best First'.
Re: Re: Re: (bbfu) (Exporter::VA) Re: Exporter::Dream
by theorbtwo (Prior) on Jan 06, 2003 at 00:23 UTC

    I don't recal you commenting on the syntax when ::VA was in the design phase -- JMD requested comments quite a bit. You're right, though -- it would be nice if ::VA did _prefix. As to the versioning, it's optional -- just set the default version equal to the current version. As to configuration, I assumed you /did/ want it because you explicitly pointed it out that it won't do it, and said it would be nice if it did (or at the very least, /asked/ if it would be nice if it did).

    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]

      I don't recal you commenting on the syntax when ::VA was in the design phase

      I wasn't there to comment on it, or I wasn't interested at that time. Anyway, I don't think Exporter::VA should be changed. To support its numerous features, lots of syntax simply has to be there. Same goes for Perl: we have a lot of syntax, because otherwise we'd need a huge amount of words to implement the same functionality. It's just not as clean as I would like an exporter to be. There's not much wrong with @EXPORT and @EXPORT_OK and %EXPORT_TAGS either: it works, and what happens is obvious. It's just not as clean as I'd like it to be.

      As to the versioning, it's optional -- just set the default version equal to the current version.

      I think there should be an alternative that doesn't even provide versioning stuff. Too often, people will use every feature that is available, just because they can. See also subroutine prototypes.

      Really, I have nothing against Exporter::VA, and would like to see it on CPAN (Why isn't it already?), and think multiple exporters can and *should* co-exist. Having alternatives is important when it comes to style :) 

      - Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[reply]
        Versioning was the main incentive for creating it. I wanted to be able to get rid of default exports in a new version of a module, while still having backward compatibility.

        The ability to do this pretty much implies aliasing. Pragmas started out as a minor footnote feature but grew with feedback that there is a larger interest in that (and it's one reason why people write their own import()).

        As for setting the default version equal to the current version, you don't "need" to do anything. If you don't declare any versioned exports, the whole concept is moot. In any case, the default version is optional and will take the current version if you don't declare it. So you can pretty much ignore features you don't need at the moment.

        If you want an exporter whose main purpose is to be small and light, I think such a design would get rid of as many features as possible. Looking at your code, I see that requiring the function names to have no sigil (rather than making it optional) simplifies the code. Keeping that note, why have non-functions supported, when by far the most common thing to export is functions. Look at what the short version code in Exporter does. Several modules define their own importer that are similar to Exporter but different. I've not looked at Exporter::Lite.

        Why isn't Exporter::VA on CPAN yet? I don't know. The powers that be seem to be slow and/or not very clear. It's in my directory, just not indexed.

        —John

[reply]

In Section Meditations