Re: How Far Can I Nest?

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!
[download]

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'

Comment on Re: How Far Can I Nest? Download Code

Replies are listed 'Best First'.
Re: Re: How Far Can I Nest? by theorbtwo (Prior) on Feb 11, 2002 at 02:05 UTC
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`	[reply]

Replies are listed 'Best First'.

Re: Re: How Far Can I Nest?
by theorbtwo (Prior) on Feb 11, 2002 at 02:05 UTC

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

[reply]