On "native boolean" in v5.40 (don't have one yet to call my own), does this produce any error|warning ...

use v5.40;
use strict; use warnings;

my @some = ( 4, 5, 6 );
print $some[ true ], q[ ], $some[ false ];
[download]

... ?

💩Sadly, no ("5 4" are printed; tried on Perl Banjo).

Cross post: https://tech.lgbt/@parvXtl/112606032658432152

Why would you want it to issue a warning in that context? Seems consistent with

print $some[ 1 > 0 ], q[ ], $some[ 1 < 0 ];
[download]

Because not to confuse|treat a boolean as integer as it happens in Lua, Ruby (someone else mentioned), Java, & Rust (code+compiler error for last 2 is below).

A C++ compiler will not complain on implicit conversion (per casual search; a Clang linter warning exists: readability-implicit-bool-conversion).

In context of Perl, was hoping that "native boolean" -- as mentioned earlier -- would actually be so and no more, to, perhaps, slowly (very) update Perl😐

Read more... Java and Rust code snippets that fail when using boolean to index (3 kB)

for(my $i = 0; $i < 10; $i++) {
    # Note to reader: Yes, could have used a trinary here, but those a
+re hard to read
    # and therefore forbidden in my codebase
    print "$i is ";
    if(!iseven($i)) {
        print "NOT ";
    }
    print "even\n";
}
[download]

The easiest code to read does not have to be read at all because the comments tell you what's happening. If one must write readable Perl then one should use its features instead writing something that looks like C. This is more perlish and way easier to read:

for (0 .. 9) {

    print "$_ is ";

    print "NOT " if not iseven($_);

    print "even\n";
}
[download]

Code should be optimized for efficient execution more than readability. Here Perl does both, since creating blocks is more expensive than postfix logic, especially inside loops. Peace

He was simply showing some of the features of the 5.40.0 release, not trying to demonstrate some beautiful or optimized code, making such nitpicking seem pretty out of place and off topic.

I semi-agree with anonymonk here - the Cish cruft got in the way of me seeing the point trying to be made. I saw C code and essentially skipped everything else. I find it really hard to imagine why you would want to write C in Perl as a preferred option. Why not just write C in C?

However I agree with cavac that the implicit variable should be avoided, but not to the extent of eschewing map and grep etc.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

I guess you're right about being off topic. Sorry I was just trying to be informative. Was triggered by reading that trinary (sic) is hard to read after seeing a multiple parameter loop in perl that was supposed to be easy to read... 🤷

$ternary = $can
? be_really_easy
: to_read_btw;
[download]

Implicit variables, e.g. $_, are banned from my project. If you use a variable, you have to name it. This makes it much clearer on first glance on what data you are working. And it makes it much easier to move around.

I should note that i'm paid to develop commercial software, meaning i always have some junior developers come and go. The goal with my code design is to make it easy to convert them from other languages. And i often have to convert code to (or from) Perl to other languages. "The most perlish way" is nearly always a bad idea, whereas a C-like for loop is available in most languages.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my rather simple sketches/one-panel comics

> Implicit variables, e.g. $_, are banned from my project.

Does it mean map and grep are banned, too? As is sort?

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Implicit variables, e.g. $_, are banned from my project. If you use a variable, you have to name it.

I agree with gramps on this one; implicit variables should be avoided ... but not to the extent of eschewing map, grep, sort etc.

I should note that i'm paid to develop commercial software, meaning i always have some junior developers come and go

Senior developers come and go too. What happens today at your company when you are away on leave? What is the company's succession plan if you decide to leave for greener pastures?

"The most perlish way" is nearly always a bad idea, whereas a C-like for loop is available in most languages.

It may depend on the company and its size, but I disagree with this general approach. In large companies I've worked for, it was common to have C++ specialists and Perl specialists. I would expect to see Perl code written idiomatically. Ditto for C++. And I would pull a face at code review if I spotted a C-style for loop in Perl code. :-)

Generally, I'm a fan of chromatic's emphasis on maintainability over "readability", described at Readability vs Maintainability References (update: note the classic "the determined Real Programmer can write FORTRAN programs in any language" and "thankfully there is not so much Fortranish Perl out there" quotes in hippo's reply ;-).

👁️🍾👍🦟

I use map a fair bit in instances like this:

$sth_insert->execute ( map { $fields{ $_ } }
  qw/ITEMNO OPTFIELD AUDTUSER AUDTORG VALUE
     TYPE LENGTH DECIMALS ALLOWNULL VALIDATE SWSET/ ) or
$log->logdie ( "Error with $insert_cmd: " . $sth_insert->errstr );
[download]

In that very limited scope, I feel it's fairly clear what $_ is. Another example:

my @good = grep { $_->{'result'} != 0 } @list;
my @bad = grep { $_->{'result'} == 0 } @list;
[download]

(And I'm sure there's a clever way to do that in one statement, and maybe someone smarter than me will suggest it.) Finally, this is also handy:

for ( 0..2 ) {

  defined $item_image_url->[ $_ ] or last;
  $new_values{ "ITEMIMAGEUR$endings[ $_ ]" } =
    $item_image_url->[ $_ ] // '';
}
[download]

That's about the largest scope that I use $_ for. After that, I tend to use $k (for key) when I'm iterating over a hash:

foreach my $k ( keys %DBhandles ) {

  $DBhandles{ $k }{ sth }->finish;
  $DBhandles{ $k }{ dbh }->disconnect; 
}
[download]

I get that having $_ appear in code can be a little odd when the scope is anything larger than Quite Small -- it stops you from grokking the code and makes you go back and figure out what the heck the value is, and where it came from.

Alex / talexb / Toronto

Thanks PJ. We owe you so much. Groklaw -- RIP -- 2003 to 2013.