Effective Perl Programming

[[ Originally entered on 1998-08-28, but not published until recently ]]

This is a list of suggestions / comments on the book, not really a book review.

Paragraphs counted as full paragraphs. Paragraph zero is a pagagraph wrapped from/to previous/next page.

Negative numbers count from end, positive from beginning.

I have characterized my comments with square brackets.

[This was originally sent only to the publisher / authors, but there was no response, so I'm adding it as an article here.]

Page 4, Paragraph 2 [Editorial]:

Definition of operator vs. application. All operators are just operators, but list operator syntax is described here.

Page 39, Example 2 [Clarification]:

"map should return a sensible value" should read "map's transform block/expression should return a sensible value."

Page 40 [Suggestion]:

"Probably slightly faster." could use justification of when/why.

Page 46, Line 1 [Editorial]:

"Use $hash{$a} and $hash{$b} to ..." should read "Use $elems{$a} and $elems{$b} to ..."

The example uses the specific variable %elems, but the heading refers to %hash.

Page 51, Paragraph 2, Line 4 [Wording]:

"I commend it to you." vs. "I recommend it to you."?

Page 66, Line -4 [Spelling]:

"automatons" is not the plural of "automaton". Should be "automata".

Page 67, Lines 10 to 14 [Comment]:

Demonstration that Perl's matching, while it may be greedy, is not ultra-greedy, since the output of this code:

$_ = 'testing';
print "matched:   $&\n";
print "memorized: $1\n";

Is this:

matched:   tes
memorized: e

Ultra-greedy matching/memorizing would have memorized 'es' for $1.

Page 96, Line -2 [Grammar]:

"...ments is flattened into a list." should read "...ments are flattened into a (single) list."

Page 108, Example [Suggestion]:

Why not use &, so that do_params takes our @_? (see pg. 97)

Page 115 [Suggestion]:

Should mention that we get a *copy* of the in-scope variables passed in to eval. So, we must be trickier if we want eval's work to effect the surrounding environment's variable values...

Page 124 [Wording]:

"...and other nested structure--one that..." should read "...and other nested structures--one [or, a way] that..."

Page 131 [Wording]:

Possible confusion over the statement: "...count of two: one due to its name and the other due..."

"its name" refers to the variable that refers to it, not to the "name" member in the example.

Pages 134-135 [Error]:

Under the heading "Nesting with map":

In the earlier discussion, we have points p0, p1, and p2:

                x       y       z
        p0      1       2       3
        p1      4       5       6
        p2      9       8       7

Now, with the structure labeled with x, y, and z in the pickets at the bottom of page 134, we are representing the values:

                x       y       z
        p0      1       4       9
        p1      2       5       8
        p2      3       6       7

If the pickets were labeled with p0, p1, and p2, we'd be representing the same structure. Also, if the values in the arrays were @x = (1, 4, 9); @y = (2, 5, 8); @z = (3, 6, 7); we would also be representing the same structure as before.

The code near the top of page 135 does indeed turn the @x, @y, and @z arrays into an @xyz array, but the resulting array is not the same as that depicted at the top of page 134.

Page 145 [Bug]:

$pat_in =~ s/(['\\])/\$1/g;

should be

$pat_in =~ s/(['\\])/\\$1/g;

Otherwise, an input string of:

'Hello, world!'

Results in:

$1Hello, world!$1

Instead of:

\'Hello, world!\'

Page 158, Item 40, Paragraph 2 [Wording]:

Line 3: "...programmers in..." or "...programmers of..."? Last sentence: "They aren't..." or "They don't form..."?

Page 169, line 2 [Fact]:

Not clear how Item 37 is about altering language syntax or semantics...

Page 173, Line 13 [Fact]:

Code: use blib "/home/hoseph/Magic"; Comment: Looks for blib in /home/joseph/Magic

Does this code cause Perl to look for blib there, or to use blib with the path name given, causing the mentioned directory to be used in module searches?

Page 180, "* cmp_file: Compare contents of two files", Lines 5-6:

Assuming the contents are the same if the file names are the same is not likely to produce good results. Makes the example weaker.

Page 208, line 4 [Wording]:

"SUPER:: refers to the current..." should be "SUPER:: refers to the @ISA list of the current..."

Page 215 [Editorial]:

In the code: print "size of data = $data{size}\n"; The fact that %data has been tied to a FileProp with the file name of "new.data" has not yet been introduced yet at this point in the example.

Page 220, Formats "B" and "b" [Fact]:

Shouldn't the "Result" column show "48" in both cases?

Page 240, Line -3 [Style]:

"... bless ... my ... thingy ..."? Cute, but a bit inappropriate (IMHO).

Page 243 [Style]:

"... compile phase, code in a BEGIN block can ..." could be "... compile phase, it can ..."

since the phrase "code in a BEGIN block" is used at the beginning of the sentence.

Page 246, Section "[^\D5]", Line 2 [Wording]:

"This character set..." should be "The character set..."

Page 252, Sectoon "Parts of a specifier" [Editorial]:

Conversion specifiers tell sprintf how to format the value it is to print for a field. The use of the word "parts" in the first sentence to refer to the components of the specifier given to sprintf is a good way to disambiguate between the field we're printing to and the components of the specifier. It would be good to maintain this terminology throughought the discussion instead of reverting to "field" in some cases.

Page 253, Table 1 [Wording]:

"... assumed infinite if omitted." should be "... indefinite if omitted."

Better still to explicitly say that entire value will be written out, without regard to how long it is.

No comments: