in reply to Global destruction feature / bug ?

To me, this behaviour makes sense because my $foo gets reclaimed as soon as the current scope is left (main::). After the main program has ended, the END blocks fire, and after that, all global variables get cleaned up.

Except (as I just realize) that our is not supposed to be a global(ly visible) variable and hence should be reclaimed at the same time as my $foo, that is, in my opinion before the END blocks are run.

One more reason to avoid our IMO.

Update: My opinion on the order of things is wrong - the order of execution/destruction of objects is exactly as it has to be because the our variable is a global variable except that the name is not visible outside the file.

Replies are listed 'Best First'.
Re^2: Global destruction feature / bug ?
by Fletch (Bishop) on Apr 03, 2008 at 14:15 UTC

    Just to play devil's advocate . . .

    The name declared by the our isn't globally visible, but the value residing in the symbol table which it refers to is a global. The only difference is the duration of the scoping of the name you're using to access it, so it's entirely reasonable that that value is destroyed along with the normal global variable cleanup pass regardless of how you're accessing it.

    (To put it another way, you would definitely be surprised if the value in the global $main::foo was destroyed just because the temporary reference to it you created with local *somepackage::foo = \$main::foo; goes out of scope.)

    The cake is a lie.
    The cake is a lie.
    The cake is a lie.

[reply]
[d/l]
[select]
Re^2: Global destruction feature / bug ?
by lodin (Hermit) on Apr 03, 2008 at 14:24 UTC

    our is not supposed to be a global(ly visible) variable and hence should be reclaimed at the same time as my $foo

    I have to disagree. our creates a lexical alias for the global variable (stored in the symbol table). 

    use Devel::Peek;

our $foo;
Dump $foo;
Dump $main::foo;

__END__
SV = NULL(0x0) at 0x24bfdc4
  REFCNT = 1
  FLAGS = ()
SV = NULL(0x0) at 0x24bfdc4
  REFCNT = 1
  FLAGS = ()

    [download]
    The alias isn't globally visible, but there's still a global variable behind it. This is how it should be. Consider this: 
    use strict;

{
  our $foo = 'foo';
  our $bar = 'bar';
}
{
  our $foo;
  print $foo;
  print $main::bar;
}

__END__
foobar

    [download]

    lodin

[reply]
[d/l]
[select]
Re^2: Global destruction feature / bug ?
by jettero (Monsignor) on Apr 03, 2008 at 14:15 UTC
    our doesn't differ significantly from use vars except that the syntax is nicer and the name is only available in the local scope even though the data is global to the namespace. I think it's well documented that our $bar doesn't go out of scope until global destruction.

    I actually think the behavior of the parent program is exactly what you should expect if you read our and my carefully.

    Please don't be down on our. It's 5.8 chic. :(

    -Paul

[reply]

      It's mostly because of that why I dislike use of our - it establishes a global variable except that I cannot get at it or change it from the outside. And in most cases I've encountered, there always comes a moment where I want/need to change a global variable. For example to add or change some configuration, or change the quote indicator from " to ' or `. And our prevents me from doing that while adding no benefit...

[reply]
[d/l]
[select]

        You sure about that? That's really not the way I'm seeing it work. It's just like use vars, but shorter and only initially available where you intend to use it. Perhaps I don't see the problem clearly. 

        test->function;
print "$test::yeah\n";

package test;

sub function {
    our $yeah = 7;
}

        [download]

        I don't see how it limits you, but I do see a clear benefit: I like it better than use vars.

        -Paul

[reply]
[d/l]

In Section Seekers of Perl Wisdom