> When writing a subroutine, think of it as a
> miniature
> program. Something is passed in, processed, and
> output. Some
> subs only do one or two of those, but many do all
> three. Try
> not to process anything that is not local to the
> sub.
That's how I think of them. I'd prefer to be able to
pass in a value, have the sub take that value into
it's own variable, process it, and then spit it back
out into the value back in the "main" or parent(in the
case that there is a sub within a sub) program. 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, I felt like I got flamed from a
few people because I was declaring my subroutines with
the number of arguments. I was told I didn't have to
so why bother. I did it for two reasons, the only
intro programming class I took taught in C, that's how
it was taught, and I happened to like that style
because of the organization, AND, in 'Beginning Perl'
the author writes about doing it that way. This was
about 8 mos ago before I had to stop working on this
to study for the LSAT. I still think of subs that
way, but think that perhaps Perl is not so much like
C, and I get the feeling that the Perl community
doesn't like the structure of C and avoids it,
sometimes passing on that sentiment to others. (I
recognize I ranted and went off on a tangent a bit, I
hope that's not too rude.)
In
> ParseLineForHomeAndVisitors(), $_ is not local to
> the sub,
> neither is @teams. It would be better to pass that
> value in:
>
See, it doesn't look like you're passing anything in
here. If I were to write it, I'd write it like this:
#sub protype declaration #this would be up at the top,
#before I even declared any variables
ParseLineForHomeAndVisitors($);
sub ParseLineForHomeAndVisitors($line) {
my $line = shift;
my @teams = ( $line =~ /([[:alpha:]]+)/g );
return @teams;
}
which may or may not work, but it seems to follow the
structure Cozens talks about in his book, 'beginning
perl', ch 8, page 254.
Perhaps this is just an internal battle with me not
understanding the syntax of perl subroutines, and not
wanting to relinquish the clarity of a C program.
> I left out the validation because the sub isn't
> named
> ParseLineForHomeAndVisitorsIfLineIsValid() and
> because, IMO,
> that's too much work for one sub. For the validation
I'd agree with that.
> I'll
> give a hint: Don't use a regex. Read three slides
> from
> M-J Dominus:
>
>
> http://perl.plover.com/yak/hw2/samples/slide007.html
>
>
Thanks. will do.
> : I tried the same thing with my hash:
> :
> : CreateAbbrevAndNicknamesHash();
> :
> : and here's the sub:
> : sub CreateAbbrevAndNicknamesHash()
> : {
> : my %AbbrevAndNicknames;
> : %AbbrevAndNicknames = (
> : IND=> "Pacers",
> : .
> : .
> : .
> : );
> :
> :
> : }
>
> The big question here is: Why a subroutine?
Style. If I had my druthers, I'd write a program with
nothing but subroutines in the "main" program. For
example, to program a robot to pour a glass of milk:
GoToIcebox();
OpenDoor();
LocateMilk();
GrabMilk();
RemoveMilkFromIcebox();
CloseDoor();
MoveToCounter();
PutMilkOnCounter();
... (I think the point has been made) :)
PourMilkInGlass();
And then below, I'd have a section called sub
definitions, where I'd define all those subs, and
maybe others that made up those subs. Writing like
this is easier on my eyes and tells me and someone
else (given my subs have descriptive names) a very
good idea of what I want to do. I write subs for
printing out a few lines of intro instructions. It
just makes sense to me. So that's why a sub.
> If you want to create a hash, create a hash:
>
> my %AbbrevAndNicknames = (
> IND => 'Pacers',
> NJN => 'Nets',
> DET => 'Pistons',
<snip>
PHX => 'Suns',
> );
>
> I don't see the point of the subroutine. If
> you want to return a hash from a subroutine,
> use 'return'. Note that foo() actually returns
> a list (or is it an array?). We decide to stuff
> the result into a hash.
>
I tried using return. It didn't work. I thought
maybe it was because I was trying to return a hash, or
trying to return the hash to a hash and not a scalar
(which would have been zero use to me).
>
> #!/usr/bin/perl
>
> use strict;
> use warnings;
> use Data::Dumper 'Dumper';
>
> my %foo_hash = foo();
>
> print Dumper \%foo_hash;
>
> sub foo {
> return (
>
I'll try it this way. I used return at the end of the
sub, after the ; but before the }.
Thanks.
SEA => 'Supersonics',
> LAC => 'Clippers',
> GSW => 'Warriors',
> PHX => 'Suns',
> );
> }
>
>
> HTH,
>
> Charles K. Clarkson
> --
> Mobile Homes Specialist
> 254 968-8328
>
>
>
>
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
