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