Re: use Switch wierdness

[Anonymous Monk]

I'm guessing this is a bug.

It is a known behaviour, Perl's "global destruction" phase doesn't obey reference counts, and the order of destruction isn't guaranteed , so $perldata gets destroyed before $c/$b,

The solution to this kind of thing is to arrange for global objects to get destroyed before and to use weak references

use DBI;

$perldata = bless { hello => 'world' }, 'superman' ;
@ARGV and $perldata = { hello => 'world' } ;

sub test {
    my( $o, $v ) = @_;
    my $m = bless { v => $v, perldata => $o }, 'TQIS::test' ;
    warn "$m $$m{v}";
    return $m ;
}

sub TQIS::test::DESTROY {
    my $self = shift ;
    warn "$self $$self{v} => $$self{perldata} ";
}

$a = test( $perldata , 'a') ;
$b = test( $perldata , 'b' ) ;
$c = test( $perldata , 'c' ) ;
__END__
$ perl junk
TQIS::test=HASH(0x3f8b5c) a at junk line 9.
TQIS::test=HASH(0x99a88c) b at junk line 9.
TQIS::test=HASH(0xa57854) c at junk line 9.
TQIS::test=HASH(0xa57854) c =>   at junk line 15 during global destruc
+tion.
TQIS::test=HASH(0x99a88c) b =>   at junk line 15 during global destruc
+tion.
TQIS::test=HASH(0x3f8b5c) a => superman=HASH(0x3f8a7c)  at junk line 1
+5 during global destruction.

$ perl junk --nobless
TQIS::test=HASH(0x99a43c) a at junk line 9.
TQIS::test=HASH(0x99a97c) b at junk line 9.
TQIS::test=HASH(0xa576a4) c at junk line 9.
TQIS::test=HASH(0xa576a4) c => HASH(0x3f8d04)  at junk line 15 during 
+global destruction.
TQIS::test=HASH(0x99a97c) b => HASH(0x3f8d04)  at junk line 15 during 
+global destruction.
TQIS::test=HASH(0x99a43c) a => HASH(0x3f8d04)  at junk line 15 during 
+global destruction.

See also Re: sub DESTROY: Strange ordering of object destruction

[tqisjim]

Muddling along with my project, I took two approaches:

1. I took out a circular link, which was necessary anyways, to avoid global destruction.
2. I'm no longer blessing $perldata- I'm oldschool enough to have learned on Perl4 anyways.

If I understand your explanation correctly, using a blessed or unblessed version of $perldata may only re-arrange an indeterminate destruction order, and therefore not a reliable solution. But then you took the same approach with your command line switch... Can you explain?

I also tested with the following code:

superman::DESTROY {
  warn "Blasted Kryptonite" ;
  }

Based on my observation, the superman object is destroyed when expected, after all the referencing objects. It's not that the references point to a destroyed object so much as the references themselves are getting clobbered. I'm probably digging too deep- If I have to think this hard in Perl, I must be taking the wrong approach.

Finally, thanks for the heads up about weak references. I was not aware of them.