[Date Prev][Date Next][Thread Prev][Thread Next] [Search] [Date Index] [Thread Index]

Re: [MacPerl] Is binmode needed in MacPerl?



>Okay - this gives me a chance to ask another question... I'm having a bit
>of a rough time grasping calling subs and how values are passed and then
>returned to/from the subroutine.

Basically, anything you put in parentheses when you call a subroutine is 
accessed in @_ in the body of the subroutine.  That's it, there are no 
other special rules.

In my case, my subroutine print_content_type takes the first argument 
passed to it (which should be the only argument) and stores it in its 
local copy of the variable $ct:

>sub print_content_type
>{
>   local($ct) = @_;
>   $ct = "text/html" if !$ct;
>   print "Content-type: $ct\n\n";
>}

That local copy is unrelated to whatever variable is passed in, except 
that they happen to have the same value.  So when I call it with:

>      &print_content_type($ct);

That could just as well be:

>      &print_content_type("text/plain");

or

>      &print_content_type($my_content_type);

or whatever.  The fact that, in my code, the global variable $ct happens 
to have the same name as the local variable in print_content_type is 
coincidence.

>I'm also trying to write a subroutine that takes a long string, and
>returns it split up into a hash. The way I want to call it is:
>
>%form = &splitter($longthing);
>
>[...] Everything I've seen just calls the subroutine, and the subroutine
>itself returns the %FORM stuff - I'd rather assign it in the main section
>of the program, where I can make the subroutine more portable, by being
>able to interchange above with something like
>
>%order = &splitter($submission);

Well, you could do this, but it's a little odd since one doesn't normally 
return associative array values from a subroutine.  Since assigning a 
list to an assoc. array will store it paired off, key, value, key, value, 
you could probably do this if you wanted to.  But it's better to use a 
typeglob.  Go check out the camel book, p. 101, for more information on 
that -- I won't try to explain it in email :-)

I find it's no big deal to have a standard library routine that splits a 
form submission into an assoc. array of standard name.  Why would you 
want to have different names for every CGI you write, except to make 
things more confusing for the maintainer?

>>Reading to and printing from a buffer of fixed size will give more
>>predictable results than "while ($image=<GIF>)".
>
>Is there any particular reason you used a 16k buffer?

Nope -- just guessed.

>Perl is
>amazingly powerful for even the simplest of jobs,

Yup ;-)

--
 Jamie McCarthy          http://www.absence.prismatix.com/jamie/
 jamie@voyager.net        Co-Webmaster of http://www.nizkor.org/
 Hate mail will be posted.