Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^2: print_r

by GhodMode (Pilgrim)
on Sep 25, 2007 at 11:15 UTC ( [id://640899]=note: print w/replies, xml ) Need Help??


in reply to Re: print_r
in thread print_r

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:
Undefined subroutine &print_r::print_r called at ./print_r.pl line 55.
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.
--
-- Ghodmode
Blessed is he who has found his work; let him ask no other blessedness.
-- Thomas Carlyle

Replies are listed 'Best First'.
Re^3: print_r
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

      grinder wrote:
      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?

      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:
      Looking more closely at the code, I suspect you want my variables and not our.

      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.

      --
      -- Ghodmode
      
      Blessed is he who has found his work; let him ask no other blessedness.
      -- Thomas Carlyle
        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.

        Point taken. I guess if I was writing this I would use Exporter, and inject the name into the current package. Then I could just use Print_r and be done with it.

        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.

        Ah, fair enough. Still seems like an odd use of our. Mind you, I think that any use of our is odd... I find that the use of my lexicals makes the intent clearer.

        Consider a lexical my $depth. You increment $depth and pass it as an extra parameter when you call the routine recursively. You then pick it up with a shift at the top. It will either be undef (called from the client code) or some positive number (current recursed depth).

        I'm probably offering you far more advice than you need; you are free to ignore it.

        • another intruder with the mooring in the heart of the Perl

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://640899]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (7)
As of 2024-03-28 22:03 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found