in reply to Should I use weaken on an object attribute containing a reference to an object which contains reference back to original object?

The problem with not using weaken has been explained.

But there's also a problem with using weaken. 

sub d {
   my $dir = Practice::Dir->new;
   my $file = Practice::File->new;
   $dir->add_file($file);
   $file->add_dir($dir);
   return $dir;
}

sub f {
   my $dir = Practice::Dir->new;
   my $file = Practice::File->new;
   $dir->add_file($file);
   $file->add_dir($dir);
   return $file;
}

# This works fine.
# `$dir` is a dir with one file.
my $dir = d();


# XXX This fails.
# `$file`'s dir is `undef` even though it wasn't before we returned.
my $file = f();

[download]

The correct solution could be neither.

  • Comment on Re: Should I use weaken on an object attribute containing a reference to an object which contains reference back to original object?
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: Should I use weaken on an object attribute containing a reference to an object which contains reference back to original object?
by LanX (Saint) on Jan 22, 2024 at 19:10 UTC
    > The correct solution could be neither.

    As I already said, this is a design problem of this "file system simulation" , and not weaken's

    I have trouble imagining a file system where dirs and files are deleted implicitly after "falling out of scope".

    Personally I would make deletion explicit with ->remove methods, and keep strong refs of the objects only in an %instance hash of the class, all other internal refs must be weak. Like this the refcount can not become 0 unless explicitly wanted.

    Now if there are still other external refs when ->remove is called, this must be resolved.

    Either they are all weak, because the constructor returned them weak and they'll become automatically undef after distruction.

    Or they are strong and the refcount is checked by ->remove and throws an error "can't remove, still in use"

    Bottom line: This scenario is too complicated to discuss weaken

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

[reply]
[d/l]
      I have trouble imagining a file system where dirs and files are deleted implicitly after "falling out of scope".

      I've re-read the OP. It doesn't seem to mention anything about actually operating on a filesystem. Rather it's just an example of collections of related objects or references.

      🦛

[reply]
        The OP wants a general advice for weaken with an ambiguous OO design.

        My point in 3 posts already is that it's not possible to answer a fuzzy question, because different readers will have different use cases in mind.

        That's a bad ground to discuss weaken thoroughly. Bad question, useless answer.

        A conclusion like

        > > > But there's also a problem with using weaken.

        looks problematic to me.

        FWIW: The only general advice I found in the perldocs on weaken is to use it on the shorter lived ref.

        Update

        Creating a decent discussion/tutorial for weaken would be nice.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]

      What the hell are you talking about? I didn't say anything about automatic file deletion. The question being asked is if the OP should be using weaken or not in a data structure that mirrors a file system.

      haj pointed out that you get memory leaks if you comment out weaken. And I pointed out that you can end up with premature deallocation if you don't. The point I was making is that just adding weaken is not a solution, or at least not one without downsides.

      Perl's reference-counting GC makes bidirectional data structures very hard to implement.

[reply]
[d/l]
[select]
        > What the hell are you talking about

        That the OP's premise is unrealistic.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery

[reply]

In Section Seekers of Perl Wisdom