docdurdee has asked for the wisdom of the Perl Monks concerning the following question:

Dearest Monks, I am attempting to build a class Foo that has an array of Bars. I would like a given Bar to be able to report, weakly, the Foos that it finds itself in.
{ package Foo; use Moose; use namespace::autoclean; has 'bars' => ( traits => ['Array'], is => 'ro', isa => 'ArrayRef[Bar]', default => sub { [] }, handles => { push_bars => 'push', all_bars => 'elements', }, lazy => 1, ); sub BUILD { my $self = shift; $_->push_foos($self) foreach $self->all_bars; } __PACKAGE__->meta->make_immutable; 1; } { package Bar; use Moose; use namespace::autoclean; has 'foos' => ( traits => ['Array'], is => 'ro', isa => 'ArrayRef[Foo]', default => sub { [] }, handles => { push_foos => 'push', all_foos => 'elements', }, lazy => 1, ); __PACKAGE__->meta->make_immutable; 1; }
From Moose and arrays of objects, adding weak_ref => 1 to the foos attribute in Bar is not the way to go. Is there a stable, reasonable way to do so or should I work up another solution?

Replies are listed 'Best First'.
Re: Arrays of circular memory references
by Athanasius (Archbishop) on Aug 26, 2013 at 04:29 UTC

    Hi docdurdee,

    Essentially, you have classes Widget and WidgetContainer, and you want each Widget object to know which WidgetContainer object happens to contain it.

    This sort of design, built around circular dependencies, is a recognised anti-pattern — and therefore a bad idea! Of course, it is possible to do this (Perl gives you more than enough rope to hang yourself), but it’s almost certainly an indication of a poor design — probably an XY Problem. Why do you (think you) want your Bar objects to know which Foo objects contain them?

    If you do really need to do this, I would be looking at storing the information you need in a hash, making that hash a class variable in package Foo, and providing Foo class methods which Bar objects can use to interrogate the hash. This will at least remove the circularity inherent in your proposed design.

    Hope that helps,

    Athanasius <°(((><contra mundum Iustus alius egestas vitae, eros Piratica,

      Thank you Athanasius! It does help. I'm working on a molecular object system (atoms, molecules, bond, angles, dihedrals, etc). The work has turned out to be something of a conceptual cleanser, and this is a good example. From the perspective of atoms and bonds in molecules, placing atoms into bonds that have bond methods and attributes is clear, and then having the atoms know that they are bonded seems intuitive from a chemical perspective. BUT, maybe not. The circular dependency makes everything more difficult when bonds break, which was what I was wrestling with and why I posted the question. The design is cleaner if the atoms don't know... leave it to the molecules to give that information with, perhaps, eventual extensions to Forest::Tree graphs of bonding patterns.

        If you just need to know when an atom is bonded or not, why not make the Bond() and UnBond() functions increment/decrement a bond counter on the involved atoms?