Just a couple of thoughts to try to get you into a Perl mindset :-)
First, note that there is a conceptual gray area between what is "a function" and "an operator". In C, I could replace all a==b's with a function is_equals(a,b), and in Perl, often functions that accept a single argument are called "operators", see e.g. Named Unary Operators (Update: and Terms and List Operators (Leftward)). That's why I look at "return values" the same, no matter if it's a return value from an operator, or a return value from a function.
In C and in Perl, the result of a true conditional is 1.
Not quite, in Perl it could also be "0 but true" (e.g. sysseek), or in theory any other "true" value.
In Perl, false can be 0 or "" depending on context. Or not. I don't like this.
Look at it this way: If in C some function that returns an int is documented to return "a true value" on success, then that does not mean it will return 1 on success, it will return a nonzero value. Just in Perl, the same abstraction also applies if a function is documented to return "a false value".
You even state that saying is_five()==1 is somehow not intuitive
Do you think that instead of if ( a==5 ), I should write if ( (a==5)==1 )? But then I have to write if ( ((a==5)==1)==1 ), and if ( (((a==5)==1)==1)==1 ), and ... ;-)
Plus, if a function is documented to return "a negative integer" on failure, like many C functions, you don't check that with somefunc()==-1 either.
I have to stop and say "wait, what is the function supposed to be returning? a number? a string? a reference/pointer?"
That's what the documentation is for... but if you wanted to be explicit in Perl, you could use if ( !(...) ) and if ( !!(...) ) (although the latter is of course redundant) - just don't use eq or == to check boolean values.
In reply to Re^5: Regex result being defined when it shouldn't be(?)
by haukex
in thread Regex result being defined when it shouldn't be(?)
by chenhonkhonk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |