You're not necessarily wrong... or right. As indicated by many of the responses, you've used a Perl construct that is an "edge condition" in the language whose behavior isn't well defined. But it's also a dubious programming construct in any language. Translating that statement to english, "conditionally define two variables, nextID and maxID and set their initial values to the first to elements of the array referenced by L IF L is true (defined and contains a non-zero value)". So if L is false, then nextID and maxID are not defined, let alone initialized -- which makes it difficult/questionable to use those variables in subsequent lines of code -- regardless of the programming language. And I agree, "use warnings" should generate a warning message for conditional variable definitions.
In "Perl Best Practices" by Damian Conway, well worth reading by beginning and veteran Perl programmers alike (and likely a bigger mental struggle for veteran Perl programmers challenged to change ingrained behaviors / Pearl programming styles), Chapter 6 on control structures starts with "use block if, not postfix if". In this case, rewritting your problematic statement as a "block if" clarifies the problem and eliminates the undefined behavior.
if ($L) {
my ($nextID, $maxID) = @$L;
}
It then becomes obvious that the statement actually accomplishes nothing as $nextID and $maxID are only defined within the scope of the if block. Once the if block is "closed" (executed), $nextID and $maxID go out of scope / are no longer defined and therefore can't be used in subsequent statements. And if you attempted to use $nextID or $maxID in subsequent statements after the closing if brace, "use strict" would generate a fatal compile time error stating that $nextID and $maxID are undefined.
And yes, as "my ($nextID, $maxID) = @$L if $L;" and the above are equivalent, they should produce equivalent Perl behaviors -- but they don't -- which arguably is a language flaw. And yes, Perl has its flaws.
So read "Perl Best Practices", I did. And consider the following paragraphs from the white paper "A Box, Darkly: Obfuscation, Weird Languages, and Code Aesthetics" by Michael Mateas and Nick Monfort. Full text available at http://nickm.com/cis/a_box_darkly.pdf. A fun read for those who....
"There is also an Obfuscated Perl contest, run annually by The Perl Journal since 1996. While Perl is quite unlike C, even beginning Perl programmers will be quick to realize the great potential for obfuscation that lies within the language. For one thing, Perl offers a dazzling variety of extremely useful special variables, represented with pairs of punctuation marks; this feature of the language nearly merits an obfuscation category of its own. Perl’s powerful pattern-matching abilities also enable cryptic and deft string manipulations. Perl is sometimes deacronymized as “Practical Extraction and Report Language,” but has also been said to stand for “Pathologically Eclectic Rubbish Lister.” The language is ideal for text processing, which means that printing “hello, world!” and other short messages can be done in even more interesting ways. Thus, the tradition of writing an obfuscated Perl program that prints “Just another Perl hacker,” arose on USENET and became common enough that a program to do this is known simply as a JAPH. The popularity of these programs is attested to by the first section of the Perl FAQ, which answers the question “What is a JAPH?” [10]
More generally, Perl has as its mantra “there are many ways to do it.” A half-dozen Perl programmers may easily know eight or ten different ways to code exactly the same thing. Because of this, obscure ways of doing fairly common tasks are lurking everywhere. A common, high-level obfuscation technique that is seen in obfuscated Perl and also in obfuscated C (however differently it may be expressed there) involves choosing the least likely way to do it. This could mean using a strange operator, a strange special variable, or an unusual function (or an ordinary function in an unusual way). It could also involve treating data that is typically seen as being one type as some other type, a view that is permissible according to the language but not intuitive."
And then try to explain these lines -- why the first produces the output 10 and the second produces the output 30 -- which is not a Perl bug.
print (5*2)*3;
print "\n";
print 5*(2*3);
print "\n";
Regards,
... Dewey
| John Deighan <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 02/17/2006 02:28 PM |
|
At 01:29 PM 2/17/2006, Chris Wagner wrote:
>At 12:46 PM 2/17/2006 -0500, John Deighan wrote:
> >OK, same caveat as before - apparent bugs in Perl are usually user
> >errors, but once again, I'm stumped. Here is my code. The problem I
> >have is in the second call to getCached(), specifically, the line:
> >
> >my($nextID,$maxID) = @$L if $L;
>
>I think this is the error. Notice the if part. If $L is undefined, nothing
>before the if takes place, including the my declaration. Put the my's up by
>themselves and all works as expected. You always have to be careful in
>strining too many shortcuts together.
That in no way explains where the values that end up in those
variables come from. Also, see my other post about the creation of
the lexical variables in statement like "my $var = <expr> if
<condition>". If I'm wrong in that post, I'd like to know why.
_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
_______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
