Re^2: Why use strict is good, and barewords are bad

[hardburn]

in reply to Re: Why use strict is good, and barewords are bad
in thread Why use strict is good, and barewords are bad

Until a new reserved word is added to the language. I could see dec used as a decrement operation equivilent to $foo = $bar - 1;. Or maybe you have a module that imports an apr() sub into your namespace for calculating Annual Precentage Rates. Or maybe something completely different.

The point is, you can't guarentee that any of those won't take a different meaning at some point in the future, so you should just avoid using them as barewords.

[Mabooka-Mabooka]

LOL:). One more to my colllection of "expect the unexpected".

My 1st guess out of jan,feb,mar,apr,may,jun,jul,aug,sep,oct,nov,dec
was "may",
second - "dec",
and only 3d - "oct"
(note that I don't Perl).

Imagine:

may $foo == $bar;
then $awk = sep($foo, $bar, 18) unless oct(18) eq int("2".dec("2.00000
+0)") 


:-).

[Anonymous Monk]

Or maybe you have a module that imports an apr() sub into your namespace for calculating Annual Precentage Rates.

As long as subs (or new buildins) without arguments return a string with the same name as they have, all will be well. I mean, if oct were to be defined that oct() eq "oct", the OPs example would not have been a problem.

[benizi]

While I like the clever solution to the problem at hand (barewords), I'm much happier that Perl chose the DWIMery of using a default argument of $_, e.g.: perl -Mstrict -lwe 'print for map oct, qw/077 777 034/'

(63, 511, 28) vs. ("oct", "oct", "oct")

[hardburn]

And if we could get around those pesky laws of thermodynamics, we could have a perpetual motion machine.