my behavior with "NULL" declarations

dsb has asked for the wisdom of the Perl Monks concerning the following question:

No, this is not an opportunity for everyone to evaluate my behavior. It's my's behavior that is under the microscope here.

All bad jokes aside, I was playing around with the trinary operator and was trying to do what I guess you could dynamic variable declaration. For what purpose? I don't know. I just wanted to see if I could do it.

Basically what I was trying to do was:

((shift @ARGV) ? $foo : $bar) = "Hello";
[download]

So whether or not there is an argument to the script would decide which variable, $foo or $bar, would be declared.

It works fine as is. But if I try to declare with my while using strict, everything falls apart and I get an error.

use strict;

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

# Can't declare null operation in "my" at trinary.pl...
[download]

So I suppose a null operation is one in which no value is returned, which makes sense because why would you use my to declare nothing.

So I'm wondering why this is considered a null operation. The trinary should return one value or the other, in the case either $foo or $bar. The only thing I could think of is that b/c strict is in effect, $foo and $bar do not are evaluated before being declared with my and so technically don't exist. But then I wondered why that didn't through a Global symbol error. And besides that, my behaves the same way and throws the same error whether I use strict or not.

Anyway, I'm at a loss. Any ideas?

dsb
This is my cool %SIG

Comment on my behavior with "NULL" declarations Select or Download Code

Replies are listed 'Best First'.
Re: my behavior with "NULL" declarations by dragonchild (Archbishop) on Jul 08, 2004 at 17:44 UTC
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	[reply] [d/l]
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]
Re^3: my behavior with "NULL" declarations by dragonchild (Archbishop) on Jul 08, 2004 at 18:18 UTC
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]
Re: my behavior with "NULL" declarations by Solo (Deacon) on Jul 08, 2004 at 17:56 UTC
But a literal works (for me)... compiler optimizations? `>type pm.pl { my ( 1 ? $foo : $bar ) = "hello"; print "foo: $foo\nbar: $bar\n"; } print "foo: $foo\nbar: $bar\n"; >perl pm.pl foo: hello bar: foo: bar: >perl -v This is perl, v5.8.3 built for MSWin32-x86-multi-thread (with 8 registered patches, see perl -V for more detail)` [download] --Solo -- You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.	[reply] [d/l]
Re: my behavior with "NULL" declarations by nightwatch (Scribe) on Jul 08, 2004 at 18:10 UTC
As far as I can tell, the my attribute needs to be declared at compile time. Solo's example works because the trinary operator is indeed optimized away, and the parse tree looks like: `1 <0> enter 2 <;> nextstate(main 1 -e:1) v 3 <0> padsv[$foo:1,2] vPM/LVINTRO 4 <@> leave[1 ref] vKP/REFC` [download] There is no "my" op. All "my" does is set some flags in the SV structure. The `S_my_kid` function in op.c doesn't seem to generate any ops - all it does it set the flags at compile time, and since that expression can't be evaluated at compile time Perl complains.	[reply] [d/l]