in reply to How to explicitly destroy an object so that all other references to it would become false?

I guess that is possible, you could for example use scalar::weaken, but I've never seen a place where that behavior would be desirable, do you have an example?

Usually, one let scopes take care of this:

use strict; use warnings; my $z = bless {}, "XXX"; my $w; { $w = \$z; } print "hurray!\n" if ! $w; print "still got \$z" if $z;

But, it would be interesting to see a good use for the solution you are asking for.

hth
Edit: unintentionally my'ed $w inside the inner scope...

  • Comment on Re: How to explicitly destroy an object so that all other references to it would become false?
  • Download Code

Replies are listed 'Best First'.
Re^2: How to explicitly destroy an object so that all other references to it would become false?
by John M. Dlugosz (Monsignor) on Feb 22, 2008 at 00:39 UTC
    I agree that the concept of "weak references" is undesirable. In C++, I use "borrower" objects of my own invention: whitepaper here.

    Basically, instead of breaking the smart pointer, or doing without, I use a different smart pointer, that uses without owning. It knows about lifetime management without participating in it.

    —John

      I have used weak refernces in one perl application I wrote some time ago, because the client insisted he would have circular references.

      In my opinion, this is almost always both undesirable and easily avoidable. There is a huge difference in beeing able to query (even efficiently) for related objects, and litter direct references all about and in both directions. Most you get out of going down that road is a huge pain trying to assess correctness.

      I'm familiar with the kind of c++ pointer design you mention, and in C++ you will sometimes need them, but most often I think one should be able to do without if one otherwise arrange things so that you tell your objects to act upon input, in stead of doing things to them directly.

      But, there is so many design considerations I have not participated in or fully understood, so I am interested in seeing cases where it might make sense.

        The compelling case that made me think through how to do it right, rather than avoid it on a case-by-case basis, was in GUI windowing. A window contains a list of its children, and the child points back to its parent. Meanwhile, I was working on asynchronous programming concepts. A "weak reference" can't work if the order of destruction is not defined. This concerned writing the functions that do the acting on input! Basically, WNDPROC in Windows, or closures binding an object and method to call queued to a server thread. When a method is being executed, the object cannot be destroyed. But between, it is fair game, and pending things will fail (guaranteed) as the graph of objects is being taken apart. Basically, think of your query idea as "reference" without using the problematic pointer. I separated the concepts of "reference" from "ownership". Without prompt destruction like I like and depend on in C++, the latter concept might be better described as "dependency".

        I agree that most relationships are not explicit because objects act on input rather than being known by each other. But I have small knots of typically 2 objects in this relationship, and the ability to separate the lookup from the use in time due to asynchronous calling.

        —John