On Sat, Oct 30, 2021 at 1:47 AM Dan Book <grinnz@gmail.com> wrote: > Currently, each punctuation variable has an $ENGLISH_NAME alias available > for readability. But this has a couple problems: it's only available if you > "use English;" which does not provide a direct indication of the variables > it's related to in the code, and was a significant performance penalty in > older versions of Perl; these issues leading to not much use of the module > and thus the knowledge of their existence has not become widespread; so > average Perl programmers finding $CHILD_ERROR in Perl code are likely not > to know it's an alias for $? or that it's a built-in variable at all, thus > reducing its effective readability instead of increasing it. > > Proposed by haarg in https://github.com/Perl/perl5/issues/18699 is to add > aliases like ${^CHILD_ERROR}, using the built-in variable form used for > other more recently added built-in variables. > > This has a few advantages: it provides a readable indication of its > purpose like those provided by "use English"; it is clearly a built-in > variable to those who have come across that syntax, and clearly not a > regular variable to those who don't; and it doesn't require an opt-in such > as "use English" as this syntax is already available for Perl to add any > new variable names. > > The risks are primarily that it doesn't end up being useful and in the > process uses up a bunch of built-in variable names - but reusing the > existing English names for any other purpose strikes me as a poor idea > regardless. It also is likely to be considered uglier than English > variables, due to the extra punctuation required. > > This may also be a tangential way to work toward addressing the problem of > rarely-used punctuation variables preventing the use of syntax for other > purposes, such as discussed in https://github.com/Perl/perl5/issues/18393. > I did a first stab at implementing this, and it didn't quite work because of the way many magical variables are lazily set up on first usage. I would expect implementing this to involve some serious refactoring of that area of the code. LeonThread Next