From: 7stud -- <bbxx789_05ss@...>
Date: 2009-02-27T05:30:40+09:00
Subject: Re: Sample Chapter from "Ruby Best Practices"

Gregory Brown wrote:
> 
> This book is aimed mostly at people with a decent technical grasp of
> Ruby but not a ton of practical experience.  The goal is to show how
> to attack Ruby problems in the way that a seasoned Rubyist might.
>

I have just about 0 technical grasp of ruby, but so far I can understand 
everything in your example chapter.  I did have to look up a few things 
in pickaxe2.


> 
> == Please help me improve the book!
> 
>  I still have a few weeks to make revisions, so whether you plan on
> buying the book or not, feel free to offer some feedback. 

Ok, here goes.

1) In this sentence:

"Builder works by capturing calls to missing methods, but if a method is 
actually defined, it’d have trouble doing its magic."

The contraction "it'd" is awkward and rarely used in conversation or in 
writing.  Substitute "it would" instead.

2) This sentence:

"For example: if XmlMarkup were just a subclass of Object, with no 
methods removed, you wouldn't be able produce this XML, due to the 
naming conflict."

The phrase 'this XML' had me looking up--instead of down.  It would be 
clearer to me if the sentence was changed to this:

"For example, if XmlMarkup were just a subclass of Object with no 
methods removed, you wouldn't be able produce **the following** XML due 
to **a** naming conflict."


3) Error here:

"The technique used here is simply to initialize a hidden_methods hash 
within the class, and then assign **then** method name as a key to the 
associated UnboundMethod object."

That seems to be a common error in the text.  You should do a search for 
'then' to find similar errors.

Also, the "a @hidden_methods" phrase is awkward.  An alternative:

"The technique used here is simply to initialize a method named 
@hidden_methods with a hash..."

I think the phrase 'within the class' is redundant, so that could be 
eliminated to make the sentence approximately the same length.

4) I found this confusing:

>> A.new 
NoMethodError: undefined method `inspect' for #<A:0x42ac34>
...
Maybe IRB bug!!   <-----***

You use "Maybe IRB bug!!" in several places, and it doesn't add anything 
explanatory to the output--quite the contrary.  I found it confusing.

5) I found the following example more confusing than what it was trying 
to explain:

-----
Think of this as a much higher-level version of simple temporary
state modification that mirrors this structure:

>> x = 10 
=> 10
>> old_x, x  = x, nil 
=> [10, nil]
>> x.nil? 
=> true
>> x = old_x 
=> 10
---------

I think the parallel assignment makes it hard to track what's going on. 
If the reader is such a beginner that you need to spell out how to save 
a value and then later restore it, how about doing it with absolute 
crystal clarity(which in my opinion can't be done with irb output):

x = "hello"
old_x = x

x = 30
puts x   #30

x = old_x
puts x   #"hello"

Personally, I think the original explanation was clear enough, and this 
example should be binned.








-- 
Posted via http://www.ruby-forum.com/.