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

I've just been experimenting with nested stuff -- hashes of hashes, hashes of arrays, arrays of hashes, (I haven't tried hashes of arrays of hashes yet...) and I was wondering quite how deep they can get

Is there any linguistic limit?

Is there a limit after which they become inefficient?

Obviously there's a problem with how easy to understand they become if you had:

$theHash{theKey}{subKey}{subSubKey}[$arrayRef]{yetAnotherSubKey}

or something like that, but it would still work, right?
--

($_=' jjjjjjuuuuuusssssssttttttttt annnnnoottttthhheeeeerrrrr pppeeeerrrrrrrrrrrllllllllll haaaaccccckkkkkeeeeeeerrrr') =~y/[a-z]//s;print;

Replies are listed 'Best First'.
Re: How Far Can I Nest?
by Biker (Priest) on Feb 10, 2002 at 20:53 UTC

    Perl as a language doesn't impose any limits here.

    Computer memory and developer understanding will set the limits.


    Everything will go worng!

Re: How Far Can I Nest?
by rob_au (Abbot) on Feb 11, 2002 at 01:05 UTC
    As Biker points out above, there are no hard and fast limits imposed on nested data structures by the Perl subsystem, the real limits on these strucutres imposed by computer resources and developer sanity. However, an interesting point which I'd like to add to this discussion is the handling, both at the level of code and developer mindset, of circular references - That is nested data structures that contain references back to a higher level of the data structure, causing a loop in evaluation.

    For example:

    my @array; @array = \@array; # ouch!

    According to Dan Sugalski here, there is no clear-cut manner to handle circular references unless you have great knowledge of the expected data set - I'd be interested however in other monks' experiences and opinions on circular references within data structures and what methods they have used to either prevent or detect such structures.

     

    perl -e 's&&rob@cowsnet.com.au&&&split/[@.]/&&s&.com.&_&&&print'

      In general, there are two methods to deal with circular references. They are DESTROY and weak refs.

      With DESTROY, you can explicity undef the references that you think might be circular. The advantage is that there is rarely a problem with undefing a reference that you no longer need. The problem is that most data-structures don't get a destroy, only objects (things that have at least one blessed ref to them, that is).

      The other method is weak refs. This is a fairly new feature (5.6, IIRC). That's one problem right off the back. The idea of weak references is that they don't count as a reference to the refcounting system, so a circular reference isn't a problem if one of it's links is weak; it can be broken by the garbage-collection system. (Nit alert: refcounting might not technicaly count as GC.)

      Using weak references does imply a more closely inspected data structure. If you use too many weak references, you run the risk of your data dissapearing because the ref count went to 0 because there were no nonweak references.

      OTOH, weak references seem less klugy to me, and have the advantage of not requiring a "controling" object to have the DESTROYer. (Nit warning: yes, destructor is the normal term, and proper English. OTOH, it doesn't contain the substring DESTROY, which I wanted, since it is the name of the function/method.)

      TACCTGTTTGAGTGTAACAATCATTCGCTCGGTGTATCCATCTTTG ACACAATGAATCTTTGACTCGAACAATCGTTCGGTCGCTCCGACGC