in reply to my behavior with "NULL" declarations

Try 
( (shift @ARGV) ? (my $foo) : (my $bar) ) = "Hello";

[download]

Except, you don't know which variable has been assigned to. (Due to an oddity with my's behavior, both variables will be declared. One will be undef, though.)

And, this type of thing is better done with hashes, but you knew that.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

I shouldn't have to say this, but any code, unless otherwise stated, is untested

Replies are listed 'Best First'.
Re^2: my behavior with "NULL" declarations
by ysth (Canon) on Jul 08, 2004 at 17:54 UTC
    One may or may not be undef. This falls under the same category as warned about in perlsyn.pod:
    NOTE: The behaviour of a my statement modified with a statement modifier conditional or loop construct (e.g. my $x if ...) is undefined. The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.
    Anyone have suggestions for expanding that text without making it more confusing? The basic rule is that my has both a run-time and compile-time effect, and the sane behaviour depends on the my being actually executed (for the run-time effect) for any path through the code that will later refer to that variable name.

    Update: I'm not sure this applies after all. Don't see how the my can have even a compile-time effect.

[reply]
[d/l]
[select]
Re^2: my behavior with "NULL" declarations
by dsb (Chaplain) on Jul 08, 2004 at 18:11 UTC
    I got the same thing when using a literal. So then its something about the shift that my doesn't like. It's weird that it's like that since that's not the piece being declared. Why would my care whether or not the condition is NULL since it only one of the other two parts that get's returned by the condition? At least I think...

    dsb
    This is my cool %SIG

[reply]
      At compile-time, the expression is NULL. At run-time, it will do stuff, but compile-time doesn't know that yet.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

      I shouldn't have to say this, but any code, unless otherwise stated, is untested

[reply]

In Section Seekers of Perl Wisdom