Front page | perl.perl5.porters |
Postings from June 2022
On Mon, Jun 27, 2022 at 10:10 AM Alexander Hartmaier <alex.hartmaier@gmail.com> wrote: > > On Fri, Jun 24, 2022 at 4:04 PM Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote: >> >> On Sun, Jun 19, 2022, at 08:23, Dave Mitchell wrote: >> >> On Fri, Jun 17, 2022 at 08:00:10PM -0400, Ricardo Signes wrote: >> > Porters, >> > >> > Here's what I think, on the matter of eliminating that pesky magic true value. >> >> And here's what I think. >> >> >> I think you and I are in agreement, except for one small matter: I think that it'd be useful to say "module evaluated to false, despite having at some point enabled yield true, which probably indicates a mistake." If this ends up being onerous, I think it's something we can do without. But I think it will help users who do what Ovid mentioned doing: writing all their code in a block. The feature under discussion is the only one that would really be affected by writing your code that way. That's why I think it's plausible it's happening. >> >> Why don't we start with just implementing the basic feature and then we have a year to think more about the warning if we want. 🙂 >> >> Also, we know it needs a name. I suggest 'module_true'. If the feature is on, then this module will be treated as evaluating true. I don't want to say 'require_ignores_false' or something because that could imply it changes the behavior of "require" in this scope. >> > 'module_true' sounds very generic. > Having 'require' as part of its name would be good, as it affects how require is behaving. > > I don't get why you wrote that one shouldn't imply that its behavior changes because that's just what it does: > - "require" ignores the return value to determine if the module was successfully loaded. It does not change how "require" acts in the scope of the feature. It changes how "require" acts when returning from where the feature is active.Thread Previous | Thread Next