in reply to Writing a REAL destructor

The DESTROY method is special because perl calls it when it realizes it can garbage-collect the object in question. If you would like to manually release the object from memory (by the way, do you have a good reason for this?), you should not call DESTOY directly, which, as you noted, will simply cause it to be called twice. Instead, you delete the last reference to the object, eg: 
my $me = new Person;
$me->name("Andy");
undef $me;

[download]
Immediately after the undef(), the object will be freed (because Perl uses a ref-counting GC) and DESTROY called.

ps. My condolences regarding Andy. 

   MeowChow                                   
               s aamecha.s a..a\u$&owag.print

Replies are listed 'Best First'.
Re: (MeowChow) Re: Writing a REAL destructor
by Dog and Pony (Priest) on Jun 05, 2002 at 08:34 UTC
    A purely theoretical follow up question (just because I am curious):

    When you undef an object, is it really freed immideately, or just marked up for collecting, while the GC decides when to really take care of it all by itself? Reason I ask is that I seem to recall that you can not trust this to happen at any given point no matter what you do - but the odds are better if you undef.

    Note that if you need that finegrained control over your memory and/or objects, if this really matters, then you probably have lots of other, more important problems, such as choice of language, hardware or the problem/project itself. :) So I am just asking technically, what really happens?

    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
[reply]
[d/l]
      I believe undefing a reference was given extra magic to act as a forceful and immediate call to action for the garbage collector. I may be wrong and objects may always be immediately collected as soon as the ref counter hits bottom though.

      Makeshifts last the longest.

[reply]
        You are indeed wrong. undef is not a garantee an object will be DESTROYed. It will only be destroyed if the ref counter goes to 0.

        Image some code like this: 

        {   my $obj = Harf -> new;
    my $obj2 = $obj;
    undef $obj;    # Does *not* call DESTROY!
    ....
}   # Only here DESTROY is called, as also $obj2 goes out of scope.

        [download]

        Abigail

[reply]
[d/l]
[select]
      A purely theoretical follow up answer (because I know very little about perl internals):

      I believe it's freed immediately. The issue you're probably recalling is that there's no orderly destruction of objects when a program is terminating. 

         MeowChow                                   
               s aamecha.s a..a\u$&owag.print
[reply]
Re: (MeowChow) Re: Writing a REAL destructor
by NaSe77 (Monk) on Jun 05, 2002 at 09:10 UTC
    i see thanks i knew tat perl uses ref-counting but now its more clear and i think i can use that ...
    i wanted to have some kind of counter which says how many instances of my class there are (therefor the variable $Census) and since some of my intances will die during my programm i thought to do it this way would be a good idea

    i still wonder if there is a way to do this some kind in sub DESTROY though

    thanks for the condulence andy was really a good guy ...

    ----
    NaSe
    :x

[reply]
      Keeping track of the number of instances can very well be done via DESTROY. I wouldn't put in a reference in the object though. Then you make the count accessable outside your class, and you probably don't want to do that.

      Use something like: 

          package MyClass;
        
    my $count = 0;
        
    sub new {
        my $proto = shift;   
        my $class = ref $proto || $proto;
        $count ++;
        my $obj = ....;
        bless $obj => $class;
    }

    sub DESTROY {
        $count --;
    }

      [download]
      And do not call DESTROY yourself. Perl will do that for you.

      Abigail

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom