in reply to overloading the print function (or alternatives)

How about a couple of sentences in the manual that say:
Slow down, cowboy! If you're thinking of skipping all of this concatenation rigamarole and just printing directly to the browser, stop. Remember, you're writing a component that has to be evaluated in the context of other components. No one knows what that's going to be until it actually happens. Take a deep breath, type 'my $str;', and you'll save yourself the time of wondering why your web browser seems to break.

It's really a behavioral issue. We can correct this with a filehandle tied to a scalar in the normal parsing mode. Every time evalCode returns, we just have to check for a chunk of CONTAINED_STUFF in the scalar, and put it in the right place. But in compiled mode, there's no good and clean way of doing that. (Mixing in calls to $tied_fh->get_and_clear() does not qualify as clean.)

I say, use the stick and not the carrot!

  • Comment on Re: overloading the print function (or alternatives)

Replies are listed 'Best First'.
Re: Re: overloading the print function (or alternatives)
by nate (Monk) on Dec 05, 2000 at 00:08 UTC
    yeah -- about how many perl hackers read the manuals before trying their kung-fu out? ;)

    The biggest problem is the context/header problem, even if it kicks out a backend error, rather than prepending to the return string, it's better than getting a dialog box which asks you where you want to save file "index.pl"...

    Of course, that might be a good lesson in using the displaytype=edit param via the URL...

    --nate