develooper Front page | perl.perl5.porters | Postings from December 2015

A more CPANish way of making the prereq explicit? [was: Proposal:Add {-as => 'new_name'} feature to Exporter.pm]

Thread Next
From:
Aristotle Pagaltzis
Date:
December 24, 2015 08:48
Subject:
A more CPANish way of making the prereq explicit? [was: Proposal:Add {-as => 'new_name'} feature to Exporter.pm]
Message ID:
20151224084830.GB89260@plasmasturm.org
* Chad Granum <exodist7@gmail.com> [2015-12-21 07:55]:
> I picked the name Exporter::ImportSpecs instead of Exporter::Rename
> since one of the benefits of the symbol => { ... } form was that it is
> extendable if needed. Naming the package that enables the
> specification of the hash after a specific feature of the hash seemed
> short-sighted. That said I do not love the name and welcome
> bike-shedding for a better one.

I agree that Exporter::Rename is too restrictive but the feature.pm-type
approach has the opposite problem of allowing a combinatorial explosion
of requested feature sets.

Requiring a particular version of the import spec so you can ask for one
of a small known set of combinations seems the saner approach in this
case.

I think this will require nothing more than adding `VERSION` method to
Export that looks something like

    sub VERSION {
        my ( $class, $ver ) = @_;
        $SPEC_WHITELIST{+caller} = $ver if defined $ver;
        goto &UNIVERSAL::VERSION;
    }

And then of course the checks in the rest of the code have to become
version comparisons rather than feature hash key lookups. It might be
a good idea to do the full-bore version comparison in VERSION and then
derive a single-integer spec version from it for storing in the hash, so
the whole rest of the code that’s trying to do a real job will not have
to deal with the full insanity that is versions in the Perl ecosystem.

The upshot is that if I want to use new Exporter features to import from
Some::Module which does not itself specify a particular Exporter version
then I have to say that like this:

    use Exporter 4.56;
    use Some::Module 'foo', { -as => 'bar' };

I think this makes it look ordinary enough to make people not even think
twice about the fact that they’re being forced to do this. Even better,
all of our existing tooling can already figure out what to do with this,
without any need for Exporter::ImportSpecs-specific logic in things such
as prereq scanners.

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/>

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About