------art_83847_4707184.1167214972384
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

>
> On 12/22/06, Jeremy McAnally <jeremymcanally / gmail.com> wrote:
> >
> > Hello all,
> > I just switched everything over, and Mr. Neighborly's Humble Little
> > Ruby Book is now available to download as a PDF or view online
> > completely free.
> >
> > You can go check it out at: http://www.humblelittlerubybook.com/
> >
> >



Jeremy,

Another suggestion is to clarify your statement in regards to conditional
link operators on
http://www.humblelittlerubybook.com/book/html/chapter3.html

You mention that the stringified versions (and,or, not) are the same as the
C version (&&, ||, !) but there is a pretty big gotcha that can occur if you
treat these the same. The stringified versions are very low priority and
thus operators like  ill end up evaluating first. This could lead to some
hard to track down bugs, so it is important to make the distinction.
Obviously the developer can force their desired priority using parentheses
but they should at least know the difference. The rails core team has
guidelines such that they recommend developers not use the stringified
versions probably to avoid these very bugs.

The following is from another post on Ruby Gotchas referencing an example
from Hal Fulton's book.

>> foo  alse
>> bar  rue
>>
>> baz  oo or bar
>>
>> baz ends up false (because  as greater priority than or)
>
> Why would anyone want  o be evaluated before anything
> else?

> The point is that 'or' and 'and' have /lower/ precedence than
> anything else, so that they can be used to chain complete expressions
> together.

Blessings,

Jeff

------art_83847_4707184.1167214972384--