Gary Stainburn wrote:
>
> On Monday 05 January 2004 3:12 pm, Rob Dixon wrote:
> > Gary Stainburn wrote:
> [snip]
> > > sufficient, or will this still tie up memory? Is there a better way?
> >
> > Hi Gary.
> >
> > We really need to see your 'delete' and 'DESTROY' methods. But you can get
> > around the problem by setting $T1 to anything that's not a reference to the
> > object. At present you're setting it to the result of your 'delete' method,
> > but you could equally write
> >
> > $T1 = 99;
> > or
> > undef $T1;
> >
> > Alternatively you could let $T1 go out of scope (at the end of a block)
> > and be implcitly deleted itself by Perl. That only works if it's a 'my'
> > variable.
> >
> > HTH,
> >
> > Rob
>
> Hi Rob,
>
> I'm pretty okay with the $T1 going out of scope, and being re-assigned, hence
> the difference between my two examples.
You seemed to think that
$T1 = $T1->delete;
did something special, whereas it's the same as
$T1->delete;
$T1 = $value;
which only works because the return value from 'delete' isn't a reference to
the object (which it could quite well be).
I think you should throw away 'delete' and write just
undef $T1; # (or let it fall out of scope)
and let the garbage collection take care of deallocating the data.
> The question was more academic, trying to cover my back in the case of bad
> programming, where a ref remained by mistake. An unlikely event with the way
> Perl scoping works.
>
> I was really looking to see if there was a way of effectively zeroising the
> refcount for the object, this FORCing the garbage collector to free the
> memory.
Not without leaving references to a non-existent object.
> The best I've come up with is to call DESTROY from within the delete method,
> and from within there deleting all the elements in the hash and undefining
> the scalar holding the hashref.
I think you're confused here Gary. Or it may be me. You can't undefine
'the scalar holding the hashref' as you don't necessarily have access to it
from within the method. The reference to the object's data is passed to the
method as its first parameter. If I write
package Class;
sub new {
bless { data => 99 };
}
sub delete {
my $self = shift;
%$self = ();
}
package main;
my $object = new Class;
$object->delete;
Then my 'delete' method can empty the hash iteself, but can't access $object
to change its value. The line
$object->delete;
would be better written
undef $object;
which would make perl deallocate the hash properly instead of just leaving
a useless object containing no data.
There's nothing special at all about the 'delete' method. It's just another
object method that you can choose to write to do anything you want. Likewise
there's not much special about the DESTROY method except that is called
implicitly by Perl when the object's reference count falls to zero.
So I don't see your point about calling DESTROY from 'delete' as you can't do
anything that way that you can't do by writing extra code right there in
'delete'. DESTROY is just another subroutine in this context.
Neither DESTROY nor 'delete' have to exist; in fact it's quite unusual to see
either of them. As I said, to help you further we really need to see what these
methods are doing.
> The way I see this, the worst that would happen is that a single scalar and
> the BLESS info associated with it would remain.
It's the object data (in this case, the hash) that's blessed, not the scalar
that refers to it. If you could lie to Perl and zero the reference count
of the object then the the hash would promptly get deallocated leaving one or
more scalar references lying around pointing to something that didn't exist.
This is likely to upset Perl quite a lot, if only because when those scalar
references are destroyed (which they must be eventually) Perl will try to
cascade the destruction and delete an already-deleted object. There's no easy
way of going round finding all the references to an object and setting them to
'undef', and it would need some C code to do it at all.
> However, as I said, it's very unlikely to happen, so I don't think it's worth
> worrying about too much. I'm thinking of mountains and mole-hills now.
Mole hills are worth considering well before they become mountains :)
Cheers,
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
