Re (tilly) 1: Tie & Destroy, OOP

The problem is that your object is in a global variable and so survives to global destruction. During global destruction Perl just goes and destroys things in an essentially random order.

This could be considered a bug in Perl (even though it was documented) and will be fixed in Perl 5.8. However note that the fix depends heavily upon the fact that Perl uses reference counting, and not true garbage collection. It would not be safe to assume that Perl 6 will necessarily have reliable support for expected destruction mechanics.

In Perl 5.6 you could work around the issue by keeping track of created objects through WeakRefs and then in an END block destroying everything that didn't clean itself up.

You might think that you could just have the ini object be responsible for cleaning itself up, regardless of whether you had a tied interface to it or not. Unfortunately data that it depends upon might be cleaned up before it is, leading to data corruption. So you are just moving the problem around, but to really solve it you need to guarantee that the destruction happens before global destruction is hit.

Comment on Re (tilly) 1: Tie & Destroy, OOP

Replies are listed 'Best First'.
Re: Re (tilly) 1: Tie & Destroy, OOP by Flame (Deacon) on Aug 09, 2001 at 21:36 UTC
Hmm, this is interesting, so what would it do if every time it was used, it was declared to be 'my' (even when it's not in a sub/package)? Does that mean it needs to be destroied before the garbage is collected? Starts experementing "Wierd things happen, get used to it" Flame ~ Lead Programmer: GMS http://gms.uoe.org	[reply]
Re (tilly) 3: Tie & Destroy, OOP by tilly (Archbishop) on Aug 09, 2001 at 21:45 UTC
Lexical or not, the question is whether the data is garbage collected before the end of the program. If it is done before then you get reliable destruction mechanics that we all know and love. If it is done in the final global destruction, data is terminated with prejudice at random. BTW another solution that comes to mind is to use a flyweight pattern for your objects. That puts all of your current objects into a convenient hash that you can iterate through in an END block to do cleanup. Doing things that way gives you 2 wins. Better encapsulation, and it solves the global destruction problem in a way that is more likely to work across versions of Perl.	[reply]
(tye)Re: Tie & Destroy, OOP by tye (Sage) on Aug 10, 2001 at 01:05 UTC
Just to be clear: lexical variables don't suffer from this problem, even lexical variables at file scope. That implies that lexicals are destroyed before global destruction begins (which I believe to be true but I haven't verified that beyond testing that lexicals don't suffer from this problem). To be extra clear: destroying a lexical variable won't necessarilly destroy the object that it references. If you have other references to that same object and any of those reference manage to survive until global destruction, then your object will survive until then as well (and can so could then suffer from misordered destructions). - tye (but my friends call me "Tye")	[reply]
Re (tilly) 5: Tie & Destroy, OOP by tilly (Archbishop) on Aug 10, 2001 at 01:27 UTC
(tye)Re2: Tie & Destroy, OOP by tye (Sage) on Aug 10, 2001 at 01:37 UTC
Some notes below your chosen depth have not been shown here
Re: Re: Re (tilly) 1: Tie & Destroy, OOP by Flame (Deacon) on Aug 09, 2001 at 21:46 UTC
It worked! I was able to get it to destroy before the garbage collection by giving it a my declaration... IE: `my %member; tie(%member, "GMS::MemberFile", UID=>3);` [download] "Wierd things happen, get used to it" Flame ~ Lead Programmer: GMS http://gms.uoe.org	[reply] [d/l]