The following book reviews are the copyright of their respective authors and no part should be reproduced without the express permission of the author. Publishers and Authors of the books reviewed may reproduce the whole or extracts of a review for their book. To request copyright permission please email webmaster@birmingham.pm.org.
All the reviews herein are the opinions of the reviewer and are not necessarily the views of Birmingham Perl Mongers and its members. If you feel a review or comment has been made in error, please contact webmaster@birmingham.pm.org to rectify the situation.
Static Link: http://birmingham.pm.org/reviews/43
Title: | Perl Developer's Dictonary |
---|---|
Author(s): | Clinton Pierce |
ISBN: | 0-672-32067-3 |
Publisher: | Sams |
Reviewer: | Brian McCauley |
My first impression of this book is that the style is, on the whole, clear and readable, and the examples are also clear and helpful. It basically covers the same material in the same depth as any Perl reference manual. The book is not, and does not claim to be, a tutorial and if you tried to use it as such you'd find that the order in which concepts are introduced surprising - most people wouldn't get around to code references, labels and version strings until after introducing subroutines.
Calling itself a dictionary, the book is not an alphabetical reference, but could be a serviceable reference manual, if it were not let down by a very weak index. The index works if you are looking up a Perl function or a Perl concept by the author's chosen name. But if you want to find out about GLOBs you'll not find them by looking up "glob", but rather you'll have to lookup the pedantically correct but less widely used "typeglob". If you want to find out about an abstract concept such as how to do a set union operation in Perl you are really stuck. The explanation of tainting can only be found by looking up the <CODE>-T</code> switch and not the word "taint".
Cross linking between sections ("see also") is not as extensive as I would like. For example there is no mention of the <CODE>qr//</code> construct in the explanation of the <CODE>/o</code> regex qualifier. Similarly the example of <CODE>#line</code>, <CODE>__FILE__</code> and <CODE>__LINE__</code> should mention <CODE>eval()</code> as this is the main time it's useful. (Most people don't get involved in using preprocessors). These examples are not atypical for the book.
More significantly, in these days when we are used to the instant gratification of the hyperlink, it is outrageously annoying to have to do a double look-up to follow cross-references - they could at least have included page numbers!
Examples often unnecessarily use features that are not related to the current topic and could cause inexperienced programmers to pick up bad habits. For example, in the example for the use of <CODE>quotemeta()</code> the <CODE>/o</code> regex qualifier is used with no explanation of what it does. In this particular case it's harmless, but many new Perl programmers become far too keen on using <CODE>/o</code> on every regex in their code, without realizing that it will cause problems if the program is subsequently changed such that the code in question is called repeatedly with different patterns. Similarly many examples use alternate delimiter characters on the match operator for no good reason.
It would be good if examples used <CODE>my()</code> more. In a well-written real Perl program very few assignments (except ones to elements of aggregates) would lack a <CODE>my</code>. It seems odd that programming examples in many books fail to reflect this. Worse still in many examples in this book even variables used within subroutines are not localized in any way - neither lexically nor dynamically. The initial introduction to variables doesn't even mention lexical scope. Late introduction of lexical variables is, IMNSHO, a bad affectation often found in Perl books that have been inappropriately influenced by the fact that <CODE>my()</code> appeared late on in the history of Perl.
The final nail in the coffin of this book is the poor proof-reading. There are just too many trivial mistakes (see appendix below) for one to have confidence in this as a reference.
So despite my initial positive impressions of this book, I'm afraid I would have grave misgivings about recommending the current edition of this book. Hopefully a second edition will appear soon with corrections.
I have not read the whole book. I have read up to page 100 and dipped into the rest at random. I found errors, on average, every few pages. In this I am counting anything that is misleading, factually incorrect or omits important information that could cause the reader to adopt bad practices. The following are the errors I have found.
p12 | The URL of perlmongers is wrong. |
p19 | <CODE>sperl</code> called on a non-suid script gives an error. |
p24 | For a Perl scalar, being dual-valued in not the same thing as being magic. <CODE>$!</code> is both. |
p27 | The typeface of <CODE>n</code> used as a metasyntactic variable in <CODE>$array[n]</code> is not distinguished from the rest of the text. |
p31 | "Perl assumes that hash keys are simple strings, but will do interpolation within the curly braces". What is this supposed to mean? It appears to be saying that the braces of a hash subscript are double-quotish. They are not. |
p32 | Explanation of a hash used in a scalar context doesn't explain that an empty hash will return a false value in a Boolean context. |
p41 | When talking of a constructor called with two arguments, the book says "new() will receive two arguments in @_". No it bloody won't - it gets three. |
p41 | "Anonymous [aggregates] are simply [aggregates] with a reference count of 1". I think this is confusing. They are in effect more like aggregates with a reference count of zero - until you store the reference to them somewhere. |
p42 | Section on circular references should contain at least a "see also" mentioning weak references. In fact weak references are not even mentioned in the index so probably don't appear in the book. |
p51 | The example used the <CODE>/o</code> regex qualifier without explaining it. This is indeed one of the very rare cases where it helps, but the program would run OK without it and this is a big problem with people over-using <CODE>/o</code>. |
p54 | "A block is [...] a loop that executes exactly once". No, that's just bare blocks, as correctly explained on p56. |
p55 | I think "undocumented" is too mild a word for the behavior of the "<CODE>my if 0;</code>" construct. The behavior is undefined. |
p58 | The "Usage" of <CODE>sub</code> implies anonymous subroutines can't have attributes and prototypes. They can even though these aren't much use unless you subsequently put the subroutine into the symbol table. |
p62 | The magical <CODE>while(<>)</code> does not create a new dynamic scope for <CODE>$_</code>. |
p62 | The <CODE>for(LIST)</code> loop syntax does not do assignment to <CODE>$_</code> (it does aliasing). |
p64 | Monspaced typeface of the word "lexical" in the section heading implies that it is a reserved word in Perl. It isn't. |
p65 | Not all pragmas are lexically scoped. |
p71 | Does not warn of the counterintuitive interaction between the <CODE>package</code> directive and <CODE>our()</code> declarations. |
p75 | The reserve word <CODE>wantarray</code> is one word. |
p75 | <CODE>POSIX:_exit</code> should read <CODE>POSIX::_exit</code>. |
p80 | If the loop control variable of <CODE>for</code> is already lexically scoped, it is implicitly redeclared as a new lexical within the loop scope as if you had specified <CODE>my</code> in the <CODE>for</code> statement. |
p80 | "assignment-and-localization" should read "aliasing-and-localization" and the example of the one-element loop should therefore come after the explanation of the aliasing. |
p84 | Description of the <CODE>while</code> statement modifier does not mention the special case for <CODE>do{}</code>. |
p82 | Redundant <CODE>local($_)</code> before a <CODE>for(LIST)</code> which does an implicit one anyhow. |
p99 | In the list of zero-but-true constants the widely used <CODE>'0E0'</code> value is not mentioned. |
p261 | <CODE>eval()</code> example to unroll a loop does not warn about the dangers of special characters in data. |
p293 | The book states that the sequence <CODE>2</code> in a regex will be interpreted as either a back-reference or as ASCII 2 depending upon whether or not there are two or more captures in the regex. It then immediately contradicts this and says it will always be interpreted as a back-reference. |
p300 | "... with the {min,max} searches, the match will absorb only as many characters as necessary and still have the match succeed." This wrongly implies that the quantifier is non-greedy. The word "necessary" should read "possible". |
p304 | The regex <CODE>/(?i:the)/</code> is equivalent to <CODE>/[Tt][Hh][Ee]/</code> not <CODE>/[Tt]he/</code>. |
p312 | Description of the <CODE>$</code> regex anchor does not explain its behavior with respect to newline characters. |
p313 | In the description of <CODE>B</code> it states, "B matches between W and W characters; thus BFOO will find FOO but only if it's preceded by a word character". Whilst it is true that <CODE>B</code> will match between <CODE>W</code> and <CODE>W</code> characters, in this example <CODE>B</code> matches between <CODE>w</code> and <CODE>w</code> characters. |
p316 | Description of the <CODE>/o</code> regex modifier does not advise to see also the <CODE>qr//</code> operator. |
p318 | The use of <CODE>$foo=~$bar</code> (implicit match operator) versus <CODE>$foo=~/$bar/</code> (explicit match operator) will make no difference to the speed as they compile to the same thing. |
p342 | In the example of using the comma operator to propagate taint <CODE>$r=$c,$r;</code> should read <CODE>$r=($c,$r);</code> |
Brian McCauley, 2004-05-12
We are one of the UK's largest Perl user groups, representing Birmingham UK to the international Perl community since 2000. We hold monthly social and technical presentations, and several of our members are now regular attendees and speakers at the YAPC::Europe Perl Conferences.
For further information about Birmingham.pm, please read our Frequently Asked Questions page.
For details about joining our mailing list, please Click Here for more details.
10th April 2024
BrewDog Birmingham
81 John Bright St, Birmingham B1 1BL.
6pm onwards
Click Here for more details.
No meeting currently scheduled
10th Apr - April Social
8th May - May Social
12th Jun - June Social
10th Jul - July Social
14th Aug - August Social
11th Sep - September Social
9th Oct - October Social
13th Nov - November Social
11th Dec - December Social
Download the Birmingham.pm ICalendar
or subscribe to our Google Calendar
Aberdeen Perl Mongers
Bath Perl Mongers
Birmingham Perl Mongers
Bristol Perl Mongers
Devon & Cornwall Perl Mongers
Edinburgh Perl Mongers
Glasgow Perl Mongers
London Perl Mongers
Milton Keynes Perl Mongers
North of England Perl Mongers
Nottingham Perl Mongers
Southampton Perl Mongers
Thames Valley Perl Mongers
• Linux System Programming
• Mastering Perl
• GIMP 2 for Photographers
• Minimal Perl
• Wicked Cool Perl Scripts
• Red Hat Linux 9 Unleashed
• IRC Hacks - 100 Industrial-Strength Tips & Tools
• eBay Hacks - 100 Industrial-Strength Tips & Tools
• Exploiting Software - How To Break Code
• Mac OS X Unleashed, 2nd Edition
* New Reviews
.. More Reviews
Individual Sponsors:
Barbie
Steve Pitchford
Alex Chudnovsky
Richard Dawe
Jon Mitchell
Greg Brown
Brian McCauley
JJ
Richard Clamp
Jon Brookes
Corporate Sponsors:
Birmingham Science Park Aston
Target Support Solutions (TSS) Ltd.
MACS Software Ltd.