in reply to Re: A curious case of of my()
in thread A curious case of of my()

The answer is that @array is global variable
Bullshit.

@array is a lexical variable.

The declaration with my is never executed because the "if" test fails.
Bullshit.

The declaration part of my is being done. Because that happens at compile time.

Try also using the strict and warnings pragmas in your coding.
The code presented is strict clean, and warnings free. Don't go pretending strict and warnings are silver bullets. They aren't.

Replies are listed 'Best First'.
Re^3: A curious case of of my()
by Anonymous Monk on Apr 05, 2011 at 10:27 UTC
[reply]
Re^3: A curious case of of my()
by LanX (Saint) on Apr 05, 2011 at 11:22 UTC
    >The code presented is strict clean, and warnings free. Don't go pretending strict and warnings are silver bullets. They aren't.

    But garlic and cheaper than bullets!

    use strict;
use warnings;
 
sub tst {
  my $y if 0;              # throws "Deprecated use of my() in false c
+onditional" => 123
#  my $y if shift;         # no warning                               
+            => 112
  print ++$y
}
 
tst(1);
tst();
tst();

    [download]

    Anything that helps should be used...

    Cheers Rolf

[reply]
[d/l]
      As I pointed out in an earlier post, the warning is only for if 0; (or anything else that at compile time gets optimized away). It will not warn in the OPs case. Besides, there's no reason to assume the OP didn't use strict or warnings. And we shouldn't give the impressions people should post complete programs instead of relevant snippets showing the problem at hand. Which is what the OP did.
[reply]
[d/l]
Re^3: A curious case of of my()
by anonymized user 468275 (Curate) on Apr 05, 2011 at 11:35 UTC
    I did of course test my assertions before presenting them. Separating the "my" from the if makes the problem go away. If the array were lexically declared it would not persist between calls to the subroutine. What do you think is happening - C static declaration leaked in there? Hardly! All of your points are in fact incorrect. In addition your style of argument is unacceptable to more educated people. Perhaps if you were more careful in your analysis to improve your accuracy, you wouldn't need to use expletives and straw men (like creating a line of argument, implying dishojnestly that another said it and then shooting it down) to sell your fallacies. I don't like dishonest people - go away.

    One world, one people

[reply]
      As already said my has a compile-time effect of declaring a lexical variable and the run time effect of initialization.

      So this variable is a lexical which just isn't resetted in further runs, because of the if condition, (such that the old value of previous runs remains in the assigned memory-slot)

      One might argue what a global variable is, in Perl context it's normally used as synonym for package variables.

      Actually I'm trying to avoid the term "global" and prefer saying "package" or "lexical"! (There are hacks to globally manipulate lexicals)

      IMHO the only acceptable least misunderstandable use of the term "global" is with special vars like $_ which always belong to main:: without full qualification, no matter which package you're in.

      $_=666;
package Foo;
print $_;      # -> 666

      [download]

      HTH! :)

      Cheers Rolf

[reply]
[d/l]
[select]
        ... special vars like $_ which always belong to main:: without full qualification

        ...unless $_ is lexicalized in the current scope :) 

        $_=666;
{
  my $_=777;
  print $_;        # -> 777
  print $main::_;  # -> 666
}

        [download]

        (just meaning to say that $_ isn't the best example — otherwise I agree of course)

[reply]
[d/l]
[select]
        hmmm - but separating the my from the if turns on the lexical scope whereas leaving it as is keeps that turned off when tested.

        One world, one people

[reply]
          A reply falls below the community's threshold of quality. You may see it by logging in.
      I did of course test my assertions before presenting them.
      Care to post the test that showed @array is a global variable?
      If the array were lexical it would not persist between calls to the subroutine.
      That's not the definition of a lexical variable.
      All of your points are in fact incorrect
      Please show some code that proves my @array if EXPR; generates a global variable. Or how enabling strict and warnings would have pointed out the problem to the OP.
[reply]
[d/l]
        It's the line "push @array ..." that auto-vivified the global array in the absence of strict declarations - the my did not take effect.

        One world, one people

[reply]

      If the array were lexically declared it would not persist between calls to the subroutine.

      Really? 

      use Devel::Peek qw( Dump );

sub f {
   my $x;
   Dump($x);
   $x = "abc";
}

f();
f();

      [download]
      SV = NULL(0x0) at 0x2cb90dc
  REFCNT = 1
  FLAGS = (PADMY)
SV = PV(0x1542f64) at 0x2cb90dc
  REFCNT = 1
  FLAGS = (PADMY)
  PV = 0x154b194 "abc"\0
  CUR = 3
  LEN = 12

      [download]

      You can tell it's the same variable in both calls to the function not only by the address being the same, but by the state left over between calls. Would you care to change you claim that this $x isn't a lexical?

      See Re: A curious case of of my()

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom