in reply to print_r
Careful: this code doesn't deal with circular structures:
my $r1 = [ 1 ]; my $r2 = [ 2, $r1 ]; push @$r1, $r2; print_r($r1);
This will recurse endlessly until the heat death of the universe or you run out of swap, whichever comes first. Then again, perhaps the PHP implementation does as well.
Minor issue: you don't want to explicitly state the package (main::print_r) when you call the function within itself. Using the unqualified name will allow it to work regardless of which package defines the routine.
• another intruder with the mooring in the heart of the Perl
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: print_r
by mwah (Hermit) on Sep 25, 2007 at 11:49 UTC | |
PHP's print_r (522) does indeed detect recursion after the first loop:
This will result in the following output:
Regards mwa | [reply] [d/l] [select] |
by Anonymous Monk on Mar 23, 2009 at 16:30 UTC | |
| [reply] [d/l] |
|
Re^2: print_r
by GhodMode (Pilgrim) on Sep 25, 2007 at 11:15 UTC | |
This will recurse endlessly until the heat death of the universe or you run out of swap, whichever comes first. Then again, perhaps the PHP implementation does as well.You're right: +1 :) I don't know how PHP's print_r handles this either. I guess a solution to this problem would be to add an arbitrary limit to the $level variable and have it stop calling print_r when it gets to the limit. I have to ask, though, why would you have an array that references itself? Minor issue: you don't want to explicitly state the package (main::print_r) when you call the function within itself. Using the unqualified name will allow it to work regardless of which package defines the routine.I did this initially, but I got the following error: To make it easy to use in other programs, I gave it's own package so that there would be no chance of another global variable with the same name in the main namespace, but I still wanted print_r to be in in the main namespace. I guess it was just a warning, but this was the only way I could get it to work without errors. -- -- GhodmodeBlessed is he who has found his work; let him ask no other blessedness. -- Thomas Carlyle | [reply] [d/l] |
by grinder (Bishop) on Sep 25, 2007 at 11:49 UTC | |
I did this initially, but I got the following error: Undefined subroutine &print_r::print_r called at ./print_r.pl line 55. Odd. If I take out the main:: prefix, and the package declaration I receive no error. In fact, I've never seen a package declaration within a subroutine. It seems strange, to say the least, and I wonder if it does what you think it does. What do you think it does? Looking more closely at the code, I suspect you want my variables and not our. As to why you want to have an object reference itself, one answer is "it makes life easier". It most frequently occurs in hierarchical structures, where one of the keys at a node will be a reference to an ancestor or sibling. It makes it easier to move around in the object without having to maintain context. Have a look at an XML::Twig object some time. • another intruder with the mooring in the heart of the Perl | [reply] |
by GhodMode (Pilgrim) on Sep 25, 2007 at 21:50 UTC | |
grinder wrote: The scope of a package declaration is from the declaration itself to the end of the enclosing block (ref: package). So, declaring the package after the opening brace of the subroutine allows me to define variables (with our) that don't pollute the main namespace, but still maintain their value outside of the scope of the current instance of the subroutine. By prefixing the name of the subroutine with main::, I'm saying that I want to call the print_r() subroutine which is defined in the main namespace rather than the current namespace, which is print_r when it's called from the subroutine. I didn't even have this in there until the error message told me that it was necessary. Are you sure you used the same code as me? This doesn't seem like the kind of error that would be different between different versions of Perl. I could declare the package before the subroutine definition and remove main:: from the lines where the function calls itself, but then I would have to add print_r:: to the function call in the main body of the code. This would make it a little more annoying to use. Also, this would force the subroutine definition to appear at the end of the script because the package declaration would apply to everything after it. I suppose that I could fix this with Exporter if I wrote a proper module, but this isn't meant to be a module, just a snippet. If I take out the package entirely and use regular variables which are defined in the main namespace anyway, then this problem goes away, but then I have a couple of variables ($level and @level_index) which have to be defined by the user in addition to just pasting the code at the end of an existing program and calling print_r(). Another potential problem is that the user needs to know about the two variables and make sure he doesn't use them in the main namespace. The way I wrote it, the user needs only to paste the subroutine into their own code and call print_r(), passing a variable reference as the argument. grinder wrote: I need to use our because I need the variables to maintain their value between calls to the subroutine. If I used my it would be a new and undefined variable each time the subroutine was called and this would break the recursion. To be specific, the $level would be 0 on each recursion. -- -- GhodmodeBlessed is he who has found his work; let him ask no other blessedness. -- Thomas Carlyle | [reply] |
by grinder (Bishop) on Sep 26, 2007 at 12:46 UTC | |