[Mastering-perl] Check out the chapters on configuration, subroutines, and Pod

[Derek B. Smith]

ok brian, again, thank you for replying.
One thing I did notice that I forgot to mention. I
noticed in some of your code you DID NOT use "best
practice" in some blocks of code. For example an if
construct you used 
if ( /string/ )
{
    print "foo\n";
}

Remembering the text from Best Practices, you guys
stated do not cuddle if or else statments on new
lines. For example best practice would be:

if ( /string/ ) {
    print "foo\n";
}
else {
    print "foo-bar\n";
}

I know its a small thing but if its titled Matering
Perl than many concepts/practices such as the one
above should should reflect or follow whats in Perl
Best practices, right?

Another thing that would be nice to see in your book
is modules that are similar to Data::Dumper such as
Smart::Comments.  I came across this in the book Perl
Hacks and thought wow this is pretty nifty and
complements Dumper well.

derek
--- brian d foy <brian.d.foy at gmail.com> wrote:

> On 9/20/06, Derek B. Smith
> <derekbellnersmith at yahoo.com> wrote:
> 
> > so how does this book differ from Programming
> Perl?
> 
> Programming Perl is a reference for the language.
> It's the bible. With
> Mastering Perl, I don't have to cover everything,
> and I can throw in
> wisdom about various things. There is what Perl
> let's you do, and the
> Camel tells you that, and then there is what you
> should do, and that's
> what I'm going for in Mastering Perl. Also, I'm
> talking about actually
> making things with Perl, where Programming Perl was
> more about the
> tools that the core language gives you. Mastering
> Perl integrates a
> lot of things that are more task specific.
> 
> Also, in Mastering Perl I'm talking a lot of dealing
> with things you
> can't control, such as other people's coding style
> and the odd things
> they do. Mastering the language means you can take
> the ball of mud
> that someone else gives you and figure out how to
> fix it. That
> includes any really odd things they did, such as
> symbol table
> manipulation (yes, people write their own
> importers), source filters,
> etc.
> 
> 
> > And I thought the path from Learning Perl to
> > Programming Perl was good, do yo really think I
> need
> > to read intermediate perl and or mastering perl?
> 
> Here's where I say a lot but don't really answer
> your question:
> 
> It's different for every person. Intermediate Perl
> has a guided path
> through making modules, and it has exercises at the
> end of each
> chapter. That works really well for some people.
> Other people, often
> those with extensive programming experience in
> several languages,
> don't need that much help and can go right into
> things. But, I should
> caution, there is a Perly way to do things, so
> sometimes experience
> with things such as Java might frustrate you when
> you try to do it the
> same way in Perl.
> 
> Although I'd really like to earn a lot of money
> through royalties, I
> don't really think everyone needs to buy every book.
> However, I've
> often bought books I didn't need, and learned
> something from a
> footnote that ended up being much more valuable than
> the purchase
> price. Since I mostly do Perl everyday, if I save a
> single hour
> because of one thing I learn, that's worth a book.
> 
> With Mastering Perl, you can look at the website
> (http://www.pair.com/comdog/mastering_perl/) to see
> it before you buy
> it. If, right now, you see some topics missing,
> there is still a
> chance for me to get them into the book :)
> 
> 
> -- 
> brian d foy <brian.d.foy at gmail.com>
> http://www.pair.com/~comdog/
> _______________________________________________
> Mastering-perl mailing list
> Mastering-perl at theperlreview.com
>
http://five.pairlist.net/mailman/listinfo/mastering-perl
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com