in reply to Storing object references internally

This looks quite a bit like Abigail's Inside Out Objects — briefly introduced in Re: Naming convention for Object Variables; and take a look at the nodes listed as a reference in Class::InsideOut - yet another riff on inside out objects..

Actually you are not storing the object itself somewhere in the class, because a hash can only use strings as hash keys. So setting

$objects{$obj} = $info_about_me;
is actually first stringifying the object — which works very well as long as you haven't overloaded the '""' operator — but it is no longer an actual reference. It's a different thing if you store the object somewhere in the hash value.

If you want to purge this info from the hash when the object is destroyed, you can do that in the DESTROY method. That's what the Inside Out Objects do.

sub DESTROY { my $self = shift; delete $objects{$self}; }

Replies are listed 'Best First'.
Re^2: Storing object references internally
by Forsaken (Friar) on Apr 23, 2005 at 09:18 UTC
    Right, wrong example perhaps ;-) In fact in the real cases where I've used it the object ref is a hash value, not a key. Does that make any difference?

    Remember rule one...
      Yes it sure does. In hash values, references remain references, so your object won't ever go away.

      One thing you can do, is use a weak reference in the common data structure. That way, it'll be wiped when the object goes away.

      Weak references can be created using weaken() in Scalar::Util. Be sure to keep the vital link to your objects a strong reference (= not weakened), because if all you have left is weak references, the object will go away and all those references will become undef.