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

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

HTH! :)

Cheers Rolf

Replies are listed 'Best First'.
Re^5: A curious case of of my() (What is GLOBAL?)
by Eliya (Vicar) on Apr 05, 2011 at 12:46 UTC
    ... 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 }

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

      I'm not sure but IIRC lexical $_ is a rather new feature...

      But thanks!

      Cheers Rolf

        It depends what you call "rather new". It was introduced in December 2007, when 5.10 hit the street. It's now April 2011, with 5.14-RC0 looming around the corner.

        More than 3 years, and the almost the life-span of 2 major releases - not something I would call "rather new".

        It's present in every Perl version that wasn't officially EOLed. Even 5.10 will be EOLed in a month, if I understand correctly.
Re^5: A curious case of of my()
by anonymized user 468275 (Curate) on Apr 05, 2011 at 12:39 UTC
    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

      Scope is another often misunderstood concept.

      For instance my, our and package follow the same scope rules (block or file scope).

      The scope decides which declaration is used at compile time too chose a "memory slot" for an (unqualified) variable. And the effect is hardcoded into the compiled opcodes!

      (i.e. either a hash-lookup in a "symbol table" of a package or "variable pad" of the surrounding lexical blocks)

      You're identifying scope with initialization, but the latter is a run time issue, which is disabled in an if-clause.

      Other languages like JS or Python follow more static mechanisms, leading to other quirks.

      Cheers Rolf

      Can you either shut up, or actually post some code that shows the variable isn't bounded by a lexical scope?

      You keep babbling on that the variable isn't lexical, but remain utterly silent when queried for some actual proof.

      A reply falls below the community's threshold of quality. You may see it by logging in.