Front page | perl.perl5.porters |
Postings from June 2022
Re: Pre-RFC: yield true feature
Thread Previous
|
Thread Next
From:
Graham Knop
Date:
June 14, 2022 16:13
Subject:
Re: Pre-RFC: yield true feature
Message ID:
CAM=m89G9EZazVHrcwGnuu4CvAekDV=O+M-r1W1VikHfYjois8w@mail.gmail.com
On Tue, Jun 14, 2022 at 6:02 PM Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> 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
This only cares that require returns a true value, and avoids calling
return again in the future if so.
> and https://metacpan.org/dist/File-FindLib/source/FindLib.pm#L55 are examples I'd pick as reference.
This just passes the value on, doing nothing with it. There are no
users of File::FindLib on CPAN that use that return value.
Neither of these would be impacted by changing the return value to be
a simple true value.
>
>>
>> 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