Look at the way Deparse uses whitespace, its subtle
| [reply] [d/l] [select] |
I don't think so.
did you recompile the output?
I can't test ATM, but most likely it depends if a function is known at compile time. Contrary to AnoMonk I doubt space matters.
Anyway IMHO the indirect object syntax should be deprecated....
Cheers Rolf
(addicted to the Perl Programming Language)
| [reply] |
I can't test ATM You gotta stop saying that :)
Contrary to AnoMonk I doubt space matters. Sure it does, it matters how Deparse places the space, because it matters to perl $ perl -w
print(two (('two' == 'five') ? 'true' : 'false'));
Unquoted string "two" may clash with future reserved word at - line 1.
^Z
Name "main::two" used only once: possible typo at - line 1.
Argument "five" isn't numeric in numeric eq (==) at - line 1.
Argument "two" isn't numeric in numeric eq (==) at - line 1.
print() on unopened filehandle two at - line 1.
That is exactly as deparsed with -p, behaves exactly like the original
| [reply] [d/l] |
> Sure it does, it matters how Deparse places the space, because it matters to perl
it depends! ;-)
> > most likely it depends if a function is known at compile time
> perl
open ONE, ">", "/tmp/tst";
sub ONE { "@_ \n Space doesn't matter! \n" }
print ONE ( TWO ); # sub-call
__END__
TWO
Space doesn't matter!
update
ALSO:
> perl
open ONE, ">", "/tmp/tst";
print (ONE (TWO)); # filehandle
__END__
> cat /tmp/tst
TWO
>
BUT:
Cheers Rolf
(addicted to the Perl Programming Language)
| [reply] [d/l] [select] |