Front page | perl.perl5.porters |
Postings from December 2015
On 19 December 2015 at 05:15, Kent Fredric <kentfredric@gmail.com> wrote:
> On 19 December 2015 at 16:57, David Golden <xdg@xdg.me> wrote:
>> Author of Module Y updates it to work around Module X's wrap (if they
>> haven't done so already).
>> I upgrade Module Y (or re-deploy) to get the fix.
>>
>> Alternatively, author of Module::Y can just manually alias a function from X
>> and nothing breaks when X changes.
>
> Its just the problem is fractalic.
>
> If you published Z to CPAN, and Z depended "Y => 0", then there will
> be systems Z encounters with the broken Y => X combination.
>
> And so Z itself is broken as soon as it exists in a published state
> while that combination is possible.
>
> And so Z also has to be updated to depend on a newer version of Y, or
> at least, a newer version of X.
>
> And anything(AA) that consumed Z also has this problem. ( depend on a
> newer version of Z, Y or X )
>
> And anything(AB) that consumed AA also has this problem. ( depend on a
> newer version of AA, Z, Y, or X )
>
> And this becomes rather annoying when the problem existed in Y for a
> single release, but for some unknown reason, all the smoke testers
> installed that without getting a newer exporter.
>
> These are the sorts mistakes that are hard to kill once they happen :/
I dont know who exactly to direct this at, so I picked your mail to reply to.
I notice that most of the discussion in this thread has centered
around CPAN *modules* that might use this feature[1].
But I don't think many CPAN modules would make use of this feature.
I think many *scripts* and *non* CPAN modules would make use of this feature.
When I think about the question "why would someone alias a subroutine"
the answer tends to be "because they want to use two subroutines from
two different modules that unfortunately share the same name".
So for instance, a practical example from work where we make use of
subroutine aliasing is where we have a constant called DEBUG which we
use for enabling trace and diagnostics features in our code that is
normally "optimised away", and one from Log4Perl which is used for
logging at the "DEBUG" level.
While no doubt there are CPAN modules that might use this kind of
rename feature, I feel pretty confident in predicting that they will
be "out in left field" type modules anyway.
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.
On the other hand, this feature is the kind of feature that makes an
*app* developer, or *business logic* developer avoid having to use
"deep voodoo" to work around problems that come up in a large
codebase.
I would much prefer to explain to some developer at $work who we hired
that does not have a Perl background[2] what this does:
use Fnorble 'some_sub' => { -as => "fnorbles_some_sub" };
than to explain what this does:
use Fnorble ();
BEGIN {
*fnorbles_some_sub = *Fnorble::some_sub;
}
The more Perl someone knows before they get introduced to type globs
and BEGIN blocks the better IMO. (And the less likely they are to
think we are all insane for using this language.)
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?
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.
[2] Given the scarcity of Perl developers out there it is not uncommon
for us to hire people from other language communities like Go, Python,
etc.
--
perl -Mre=debug -e "/just|another|perl|hacker/"
Thread Previous
|
Thread Next