Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: yield true feature
Thread Previous
|
Thread Next
From:
Alexander Hartmaier
Date:
June 14, 2022 16:02
Subject:
Re: Pre-RFC: yield true feature
Message ID:
CAB49QraVMPcCbzD85iccxYQ6sWrfGiAvyqdK_gKBp52CzL+1BQ@mail.gmail.com
On Tue, Jun 14, 2022 at 11:33 AM Graham Knop <haarg@haarg.org> wrote:
> On Tue, Jun 14, 2022 at 8:15 AM Alexander Hartmaier
> <alex.hartmaier@gmail.com> wrote:
> >
> > On Mon, Jun 13, 2022 at 12:43 PM Graham Knop <haarg@haarg.org> wrote:
> >>
> >> On Mon, Jun 13, 2022 at 12:21 PM Alexander Hartmaier
> >> <alex.hartmaier@gmail.com> wrote:
> >> >
> >> > On Sat, Jun 11, 2022 at 10:37 AM Neil Bowers <neilb@neilb.org> wrote:
> >> >>
> >> >> > Can someone show an example, ideally on CPAN, where this gets used?
> >> >>
> >> >> I _think_ you were asking for an example of someone using the return
> value from a require. In which case:
> >> >>
> >> >>
> https://grep.metacpan.org/search?qci=&q=%3D%20require&qft=&qd=Acme-MetaSyntactic-Themes&f=lib%2FAcme%2FMetaSyntactic%2Funicode.pm
> >> >>
> >> >> This is in BooK’s Acme::MetaSyntactic::unicode module (yeah, Acme):
> >> >>
> >> >> if ( $] >= 5.006 && $] < 5.007003 ) {
> >> >> eval { $data = require 'unicode/Name.pl'; };
> >> >> }
> >> >> elsif ( $] >= 5.007003 ) {
> >> >> eval { $data = require 'unicore/Name.pl'; };
> >> >>
> >> >> # since v5.11.3, unicore/Name.pl creates subroutines
> >> >> # they end up in our namespace, so get rid of them
> >> >> undef *code_point_to_name_special;
> >> >> undef *name_to_code_point_special;
> >> >> }
> >> >>
> >> >> Guessing there may be other examples on CPAN – this is just the
> first one I found with grep.metacpan.org.
> >> >>
> >> >> Neil
> >> >>
> >> >
> >> >
> >> > Thanks for the grep.metacpan.org link, haven't thought about it for
> finding examples. I've looked at some others and using the return value of
> a require call is used quite frequently. So option 3 isn't a good one in my
> opinion, as a module changed to use the feature, most probably with 'use
> v5.38;' not thinking about the enabled feature, which would lead to another
> module failing because of the changed behavior.
> >>
> >> Anything relying on the return value of require as being anything
> >> other than true is already broken. The second time require is called
> >> for a module, it will turn true, not whatever the module tried to
> >> return. unicode/Name.pl is meant to be loaded via do, not require, in
> >> addition to being internal only.
> >>
> >> Going back to perl 5.30, the last version Acme::MetaSyntactic passed
> >> its tests on, it still fails if you cause Name.pl to be loaded early.
> >>
> >> $ perl -e'use strict; use warnings; use charnames qw(greek); use
> >> Acme::MetaSyntactic; my $meta = Acme::MetaSyntactic->new("unicode");
> >> die "no names!" if !$meta->name;'
> >> no names! at -e line 1.
> >>
> >> I'd say it's better to cause these things to always fail, rather than
> >> allowing them to sometimes appear to work.
> >
> >
> > Look at some of the other modules using the return value of require from
> the grep.metacpan.org link.
>
> Do you have a concrete example?
>
> I've just removed the dist filter from Neils query, added *.pm to get rid
of the dist.ini matches and looked at some modules:
https://grep.metacpan.org/search?q=%3D+require&qd=&qft=*.pm
For example https://metacpan.org/dist/DT/source/lib/DT.pm#L49 and
https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples
I'd pick as reference.
> For most cases I saw, changing the module or file to always return
> true (as in !!1) would either not make any difference, or would cause
> immediate, obvious, breakage. Either of which is fine.
>
Thread Previous
|
Thread Next