Stuart White wrote:

>   I've tried this the only way I know how, which is to
> declare the subs with the number of arguments they are
> to take, and I believe the type of argument they are
> to output (like you might see in a C program), and
> then created my variables within the sub.  Two things
> happened, when I couldn't get one of them to work and
> asked for help here,

The problem here is that you are working with different syntax.  Perl prototypes
have a very specific meaning and purpose that is different than that used in C.
I definitely enjoy--and prefer--using prototypes when working with C.  In fact,
I really don't have choice, but I find them useful.  In Perl, you do the work
elsewhere.  A well-constructed first line or two in a subroutine can serve much
the same purpose as a function signature:
sub do_something {
   my $object = shift;
   my ($this_var, $that_var, $thuther_var) = @_;
...
Since Perl is an untyped language, you are not going to get much more
information from a header anyway, so the key is in choosing good, evocative
names.

It is very important, when working with any language, to take it on its own
terms.  Good practice for law, too.  You could try looking at Perl subs as
having a built-in prototype
list sub (list @argv);
This does shift the responsibility for validation into the implementation.  You
just have to work with that.  Keeping your function definitions compact will
help.  If you can see all affected lines of the scope in one screen, it is much
more straghtforward to evaluate what is going on throughout the function.  That
is another reason to avoid globals, and take references to any data you may have
to modify as arguments to your subs.

Sounds like this is frustrating for you, I know, but stick with it.  Perl subs
and scoping do have a logic of their own.

Joseph


-- 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>


Reply via email to