Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re (tilly) 5: Tie & Destroy, OOP

by tilly (Archbishop)
on Aug 10, 2001 at 01:27 UTC ( #103642=note: print w/replies, xml ) Need Help??

in reply to (tye)Re: Tie & Destroy, OOP
in thread Tie & Destroy, OOP

Not true. On 5.005_03 try this:
my $foo = be({name => "foo"}); my $bar = be({name => "bar", data => $foo}); my $baz = be({name => "baz", data => $bar}); sub gotcha { $bar->{"bar can't go"} = "until this function is cleaned up"; } sub be { return bless shift; } sub DESTROY { my $self = shift; print "$self->{name} died\n"; } __END__ on 5.005_03 for me prints: baz died foo died bar died
Note that $foo is going away before $bar. Remove the function holding $bar to global destruction and everything will clean up properly. Make them all global and you will again run into trouble.

Replies are listed 'Best First'.
(tye)Re2: Tie & Destroy, OOP
by tye (Sage) on Aug 10, 2001 at 01:37 UTC

    You can also just store a reference to your lexical in a global to simulate the same thing. Yes, "global" "closures" are probably harder to notice than global variables, but the same basic principle applies: keeping a reference to something around prevents it from being destroyed (until global destruction, of course).

    But none of that changes the fact that you can avoid the problems with misordered destruction by using only lexical (including making sure that any references to said lexicals are also only in lexicals, etc.). That is a very practical bit of information.

    Also, current versions of Perl create a reference loop for "real" closures and so they would also cause you problems (as well as leaking memory if you create lots of closures).

            - tye (but my friends call me "Tye")
      Yes, you can do the same with a global variable. However my point was that even with every lexical in file scope, having one of the direct references to a lexical inside of a function brings the problem back.

      BTW the more I think about it, the more I like the idea of having a flyweight implementation with an END block to kill all of the objects. That allows module authors to create objects which clean themselves up reliably without assuming that users are cautious.

        That (flyweight strategy) doesn't really solve the problem since you still end up destroying objects in a random order. It will help with multiple objects from the same module having a special order that is required (so long as you design your own way to keep track of this special order which may boil down to you reimplementing your own form of reference counting), but if you have two modules that reference each other in some general way, then using a END-based destructor is just as bad as Perl's global destruction problem (except that Perl's problem will be fixed soon).

                - tye (but my friends call me "Tye")

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://103642]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (2)
As of 2023-03-30 05:14 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (73 votes). Check out past polls.