develooper Front page | perl.perl5.porters | Postings from April 2022

Re: Pre-RFC: a `library` keyword

Thread Previous | Thread Next
From:
Ricardo Signes
Date:
April 5, 2022 23:58
Subject:
Re: Pre-RFC: a `library` keyword
Message ID:
cb8d2949-80bb-4b20-938f-f78c62295eaa@beta.fastmail.com
On Tue, Apr 5, 2022, at 06:19, Salvador Fandiño wrote:
> But why not to just lift the requirement for modules to return a true value?

I'm not unsympathetic to this position, but I do think people have relied on this in various ways that I don't quite condone, like:

package Win32::Foo;

sub foo { ... }

$^O eq 'Win32';

But another argument is:

1. I don't think we want to change this without a feature flag.
2. Making the change as "this unit will evaluate to true" means putting the feature in that unit, so it controls its own meaning.
3. Making the change "true value no longer required" means putting the feature in the library that does the "require", and will then affect code that doesn't know its true/false value has changed.

This gets to one of my main ideas about good feature flags:  they need to actually make sense lexically.  A feature flag that changes how remote code works is a bad (or at least dangerous) feature flag.  You can make an argument that #3 doesn't *quite* change the behavior of code not in its scope, but I'm not sure I agree it's in keeping with the right spirit.

The goal should be (imho) "writing vX atop your code eliminates other boilerplate *in your code*."

So I think we want a "use feature 'truemodule'" that injects a true value into the end of the evaluation of the file, and can only be used at the top lexical level.  But I haven't thought deeply about that part…

-- 
rjbs
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About