Stuart White <[EMAIL PROTECTED]> wrote:
:
: > I'm sorry about that. I didn't mean to flame
: > you. It just seemed like you were taking the long
: > way around to solve the problem.
:
: It was a year ago. I don't remember who it was, and
: it's not a big deal anymore.
I've been here awhile and I'm pretty sure it was
me. I'm glad you came back. :)
: My background in C extends to pointers -- I'm still
: the novice there. :)
I am a complete moron when it comes to C.
: > Okay. In perl everything is passed into the sub
: > with a special array called @_. Let's call a
: > subroutine named link(). (I'm going to use list and
: > array interchangeably here. They're not really the
: > same though.)
: >
: > print link( '/perl/', 'Learning Perl' );
: >
: > Behind the scenes, perl creates a list of the
: > two arguments
: > '/perl/' and 'Learning Perl' and sets it equal to
: > @_. It then
: > passes control to link().
: >
:
: Before we go on, what if you had $a='/perl/'; $b =
: 'Learning Perl';
: then did:
: print link($a, $b); <-that's how I'd pass
: information, as variables, not literals.
: Does this change what comes next?
No. I used literals to shorten the example.
BTW, avoid using $a and $b for variable names, even
in examples. They have a special meaning in the perl
'sort' function.
: This is all making sense, sort of like when shift
: operates on $_.
Yes, but 'shift' operates on @_ not $_. That would
make sense because 'shift' is shifting a list (or
array). Perhaps you are thinking of 'split'. It
operates on $_ by default.
: > In perl, declaring subs at the top of the
: > script is necessary when using prototypes.
:
: It's not necessary otherwise?
No.
: Like:
: #sub declarations
: sub ParseLineForHomeAndVisitors;
: sub link;
:
: That's how I do it, whether or not there is something
: I want to pass or return with the sub.
: > Prototypes in perl do not work the way you are
: > using them. They do not declare a variable. They
: > restrain the type of values which can be passed to
: > a subroutine.
:
: So when Cozens uses something like:
: sub link($$);
: if he were passing arrays, he'd do:
: sub link(@@);
: and hashes:
: sub link(%%);
: Is that correct? That's what it seems you are
: saying.
Yes, that seems correct.
Again, though, it seems too limiting to me. This
example fails because perl doesn't see the return of
foo() as two scalars.
sub anchor($$);
print anchor( '/perl/', 'Learning Perl' ); # works
print anchor( foo() ); # fails
sub anchor($$) {
my( $href, $name ) = @_;
return qq(<a href="$href">$name</a>);
}
sub foo() {
return( '/perl/', 'Learning Perl' );
}
Note: It turns out that 'link' is a core function, so I
changed it to anchor() for testing.
We would need this use anchor() as is:
my( $href, $name ) = foo();
print anchor( $href, $name );
You may find that warm and comfy. I find it a pain
in the ass. TIMTOWTDI.
: > Perl prototyping handles this type checking for
: > the programmer, but it still uses @_ to pass
: > arguments for the sub. I have always found
: > prototypes too restrictive. I understand why you
: > are using them, but I still think life will be
: > easier if you abandon them.
:
: Restrictive, but protective. I find perl to allow
: too much freedom. And, as a novice programmer, I'd
: rather be as clear as day. But I see your point.
You say tomato, I say tomato.
Okay, that doesn't work in print. :)
How about a quote from 'perltooc' by Tom
Christiansen:
"Perl believes in individual responsibility rather than
mandated control. Perl respects you enough to let you
choose your own preferred level of pain, or of
pleasure. Perl believes that you are creative,
intelligent, and capable of making your own decisions-
-and fully expects you to take complete responsibility
for your own actions."
: > I agree. However, that shouldn't be the goal
: > (in perl) for a beginner. It is possible, but it
: > requires the knowledge you'll obtain by using some
: > data structures.
:
: I'm not sure what you're saying here.
You could achieve your goal of programming with
only subroutines by using objects. In perl an object is
(normally) a blessed reference to a data structure.
IMO, the more you already understand data structures in
perl the easier it will be to move toward objects in
perl.
: > : 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.
: >
: > In perl, one problem with using a sub this way
: > is that it forces the use of global variables. If
: > %AbbrevAndNicknames has not been declared above the
: > subroutine, how else will you pass it around the
: > script?
:
: Hmm, not sure. I used to be able to do it in C,
: without globals, but I haven't gotten that far in
: perl.
I think we are running into my C ineptitude here.
: > You might want to depend on the documentation
: > that comes with perl more than the book you are
: > using. 'perlfunc' has a listing of almost all the
: > functions you'll see here. Perldoc.com has handy
: > html documentation for the major versions of perl.
: > 'Perlsub' does a better, deeper job than me with
: > subroutines.
:
: Yeah, I had this problem before. Someone told me to
: go to
: Start->Program Files->ActiveSTate 5.8->Documentation
: This gave me what I find at the manpages, not perldoc.
: It was laid out well, but it was confusing.
I had the same problem with the documentation. It
is easier now, but the first few months were very
frustrating. I hate the way perlfunc is laid out. I
added an alphabetical function listing to it, just for
looking up unfamiliar functions I find in programs.
[snipped script]
: I understand this one, but not the one below.
: I'm not sure what is supposed to be in @_. And I'm a
: bit confused why you're using a reference.
:
: little help?
Oh, sure delete the one below! Make /me/ go look
it up! :)
In that script I am passing the file handle DATA to
a subroutine. If I have strict 'subs' turned off, I
could use this and everything would be fine:
my @teams = fetch_teams( DATA );
With strict 'subs' back on this would work:
my @teams = fetch_teams( 'DATA' );
The problem is that I am not really passing a
variable to fetch_teams(). I (think) I am passing the
name of a variable and because of the way the diamond
operator works, no error is raised.
According to perlsub the preferred methods to pass
file handles are:
my @teams = fetch_teams( \*DATA );
my @teams = fetch_teams( *DATA );
I learned to do it with a reference and tend to
forget about not using the reference.
HTH,
Charles K. Clarkson
--
Mobile Homes Specialist
254 968-8328
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
