On Wed, Mar 25, 2009 at 14:47, Chap Harrison wrote:
> Thanks - I have ordered, and now received, not only Intermediate Perl but
> Perl Best Practices. Yum.
snip
It is important to keep the following bit from Perl Best Practices in mind
while reading it:
Use this book as a starting point for
Thanks - I have ordered, and now received, not only Intermediate Perl
but Perl Best Practices. Yum.
Chap
On Mar 24, 2009, at 12:05 AM, David Christensen wrote:
Chap Harrison wrote:
Now I'm writing a suite of tools that will share a lot of the same
functionality, and the right thing to do i
Chap Harrison wrote:
> Now I'm writing a suite of tools that will share a lot of the same
> functionality, and the right thing to do is factor that into a single
> source in some way. Something equivalent to #include "foo.c"
You're ready for Intermediate Perl:
http://oreilly.com/catalog/97
On Mar 23, 2009, at 10:47 PM, Chas. Owens wrote:
Modules are the way to go. They are not as complex as they seem to
you right now. Here is a simple module:
[snip]
I can't thank you enough for your patience and time putting together
that introduction to modules for me. This helps to demys
On Mon, Mar 23, 2009 at 19:41, Chap Harrison wrote:
snip
> I suppose what I want is the "module" (I mean, it just *sounds* right), but
> from what I've read so far, Perl modules seem to be very advanced,
> general-purpose animals - found mainly in CPAN, or in object-oriented
> programming.
snip
M
Look at the documentation for Use require
Sent from my iPhone
On Mar 23, 2009, at 7:41 PM, Chap Harrison wrote:
Hi,
Until now I've written Perl in a quick-and-dirty fashion - single
monolithic .pl file, cutting and pasting from previous code where
convenient, etc. Often I won't even wri
Hi,
Until now I've written Perl in a quick-and-dirty fashion - single
monolithic .pl file, cutting and pasting from previous code where
convenient, etc. Often I won't even write subroutines. (It's not how
I generally program, but it has filled the bill well for the kinds of
things I've
