in reply to Re: subroutines and namespace
in thread subroutines and namespace

Warning. That eval solution needs error checks. Else you could get very confused working out why you are getting no result, when the problem is that $routine expects to be sharing some variables with its environment, the environment doesn't have them, and strict finds this to be a situation worth complaining about.

(Just to list one non-obvious way that a non-trivial error in $routine may need to be handled.)

UPDATE
Re the reply, I understand fully. I just like pointing these things out because you have to expect people to just lift code from here directly without understanding the issues. So if you are posting it as a suggestion, it should look like production code.

That said, I find the eval solution painful on the face of it. I would prefer to solve that with just using Filter::Simple and a few well-chosen macros. If I was going to solve things that way. Which I would probably avoid for reasons listed above...

  • Comment on Re (tilly) 2: subroutines and namespace

Replies are listed 'Best First'.
Re: Re (tilly) 2: subroutines and namespace
by jepri (Parson) on Nov 03, 2001 at 11:46 UTC
    The perils of doing an off-the-cuff answer to a post. When I implemented it I eventually had buckets of error checks in the routine itself (e.g.  if defined) and checked the results with an or die "\$routine failed with error $@". I also had almost every second line printing into a log file (my personal favourite way of documenting code).

    But after that there's not much difference between the evals and real subs except some faulty code can stomp all over variables in your current namespace.

    ____________________
    Jeremy
    I didn't believe in evil until I dated it.