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

Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm

Thread Previous | Thread Next
From:
Kent Fredric
Date:
December 20, 2015 08:38
Subject:
Re: Proposal: Add {-as => 'new_name'} feature to Exporter.pm
Message ID:
CAATnKFBzB6at06AsCgjf+d361_caO0wPVpWVcDZp-dG0L50XwA@mail.gmail.com
On 20 December 2015 at 14:38, demerphq <demerphq@gmail.com> wrote:
> So I feel like the arguments in this thread that boil down to "this
> might cause some kind of problem for CPAN authors" is somewhat tilting
> at windmills, and is trying to prevent a problem that in practice
> really wont be very common at all.

When I identify what I imagine to be a potential issue, I don't
mentally implicitly infer that the issue in question should be used as
a reason to block a feature.

Its more a representation that I expect a future problem based on past
ones, and we need to consider a prospective remedy for that problem
before it happens.

That remedy *could* be the avoidance of a feature, but it could also
simply be an alternative way of implementing the feature not to
stumble into that footgun minefield.

> A last point I would like to raise is that not too long ago Exporter
> was modified to *export* its *import* function instead of inheriting
> it. This is also a feature many "Exporter like" modules expose, and as
> far as I know there was no or little controversy with THAT patch. Why
> is this one different?

Because that only modifies things that consume exporter directly at
best, and has no visible difference from consuming modules standpoint
( its a single-layer effect ).

Changing the syntax of every module that uses Exporter however is a
much wider spread and deeply propagating change.

More over, this proposal ( or at least, some variants of it )
suggested changing the API of not Exporter.pm, but of the *literallly
thousands of modules* that use Exporter.pm to provide an import sub,
without those thousands of modules having any involvement in the
matter.

Additionally, that "import" feature addition to Exporter was not
controlled at any level other than the direct point of consumption,
and even then, that feature was *only* available if you *expressly
requested it*

  if ($pkg eq "Exporter" and @_ and $_[0] eq "import") {
    *{$callpkg."::import"} = \&import;
    return;
  }

So it has quite literally none of the risks of non-consensual API
change at a distance, and none of the dependency management headaches.
Each module serves only as a single point of responsibility, and its
responsibility is only to request a new enough Exporter to provide an
import method, and to request Exporter to export the import method.

In contrast, this change inverts responsibility of dependency
management to the consumer of the exporting module.

Which by proxy means that this change ( without any guards like
Exporter::Rename ) adds potential burdens on everyone who uses an
exporting module to not only depend on that exporting module, but to
depend on a new enough exporter, just to avoid a footgun in dependency
management.

>
> Cheers,
> yves
> [1] Hardly surprising given the very strong module/library bias in the
> Perl community. They way you get a name in our community is by writing
> CPAN modules, or patching core. Thus people in our community sometimes
> appear to be almost monomaniacal in their focus on modules and CPAN.

Fwiw, Theres an idea I see here that I consider relevant and have observed.

Programming happens in 2 major phases in life cycles, diverging and converging.

- You produce a product
- Confusion arises about how product should work and different people
have different opinions.
- People get mad at each other and forks happen
- Everyone goes off on their own direction and discovers cool new
stuff and stumbles into major traps
- Eventually you have too many competing products all stuck with
maintaining bugs and weird interfaces for compatibility reason
- People identify the major strengths in all the competing products,
all the design things that are not useful in the competing products.
- People then and seek to distill those strengths back into a central
product that more people can use
- And they do so also while avoiding the defects in technique and
interface that they discovered in the divergent phase.
- And this either leads to an existing product being improved to adopt
the new things, or developing a best-of-breed product that
out-competes the previous leader ( See also what is happening in the
Path and Slurping space )

In this context there's no "bad" or "good", software just becomes an
evolving organism in a changing ecological space, and as the change in
ecological demands occur, software can either mutate into new
software, hybridize with other software, or die[1]

Evolutionary pressure thus gives us improvement over the long term,
regardless of what happens relative to our "good" or "bad" software
concepts.

I just think CPAN has had a lot of the "diverge and explore" phase
(TIMTOWTDI) and we're having parts of a convergence phase (BSCINABTE).
So these are really complimenting ideologies, not competing ones. :)

[1]: And that's what a lot of CPAN is: Fossils of evolutionary
products that failed to fit the ecology and died. But unlike living
organisms where extinction is forever, times can change, and dead
things on CPAN can come back to life. So CPAN is basically an archive
of Zombie Fossils and I'm having to reference Necromancy again in a
Perl context.

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Thread Previous | 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