Front page | perl.perl5.porters |
Postings from June 2022
Den 07.06.2022 06:59, skrev Tony Cook:
> On Tue, Jun 07, 2022 at 09:16:22AM +0900, Yuki Kimoto wrote:
>> 2022-6-7 7:07 Neil Bowers<neilb@neilb.org> wrote:
>>
>>> This is a retrospective Pre-RFC for a proposal from Curtis, for which he
>>> submitted a draft RFC[1]. We nearly missed it when reviewing proposals
>>> in-flight in our PSC meeting last week, and decided to trigger a discussion
>>> here, to reinforce the process.
>>>
>>> ...
>>>
>>> [1]https://github.com/Perl/RFCs/pull/16
>>>
>>>
>> I want to hear the haarg' proposal a little more.
>>
>>> There is another model that could be used. could always ignore the return
>> value from the file if the feature was enabled. This is simpler than the
>> previous option, but accomplishes essentially the same thing. It still
>> needs special handling in , but doesn't need to care about an implicit vs
>> explicit return. In practice, the return value from a ed file is not usable
>> for anything. The only impact it will have on perl's behavior is throwing
>> an error for a false value. This is better done by throwing a real error.
>> If there is no real purpose for returning an explicit value, why complicate
>> the model by trying to handle specially?
>>
>> Does this mean changing the behavior of "use", "require", "do" in the
>> "yield_true"
>> feature?
> There would be no change for "do", it doesn't require truthiness.
>
> Simply removing the requirement is close to trivial (below), but I'd
> expect it to break some downstream tests. It breaks a small number of
> tests in core, including one for parent.pm.
>
> Tony
>
<diff of perl5 changes needed>
Seeing how the lexical/global etc discussions are going with
clarifications needed even among savvy perl hackers – I wonder – why
this particular route (ignore return value (and croak if file is not
found or not compiled)) under a new version isn't the best route?
I think the test in parent.pm seems to be testing that parent.pm dies if
the included file returned false.
I believe `require` is often wrapped in eval and saves its state so you
can't run execute the module several times (easily) and for general
dynamical modules people tend to use Module::Load or similar?
As for do, it might not require truthiness in itself, but a user might
rely on the return value when using it in like in the `perldoc -f do`
examples:
# Read in config files: system first, then user.
# Beware of using relative pathnames here.
for $file ("/share/prog/defaults.rc",
"$ENV{HOME}/.someprogrc")
{
unless ($return = do $file) {
warn "couldn't parse $file: $@" if $@;
warn "couldn't do $file: $!" unless defined $return;
warn "couldn't run $file" unless $return;
}
}
but I guess it still wouldn't need any change per se.
Are there examples of people utilizing the last/return value of a
included file to state an error in CPAN or in the wild?
--
Nicolas Mendoza
Thread Previous
|
Thread Next