----- Original Message -----
From: "Rudolf Polzer" <AntiATField_adsgohere / durchnull.de>


> The problem is just that this if line is equal to Pascal's:
>
>   if foo = nil then
>   begin
>        { ... }
>   end
>
> Note that the first line is completely equal. When reading the above
> code, I'm tempted to "parse" it as Pascal code and oversee the
> assignment.
>
> > Also, you know, the parentheses are really
> > optional in the condition, independent of all other things.
>
> The problem is just, that it:
>
> - looks better with the "then"
> - if the "then" is there, it looks like Pascal
>
> But I just found a workaround (which already works):
>
>   if foo == nil; then           # bash-like
>     # ...
>   end
>
> Maybe it's less tempting to write a Pascal-style equality test if the if
> syntax does not look exactly like Pascal.

Instead of finding "workarounds" to make Ruby look like Pascal or Bash, why not
just learn Ruby properly?  Use -w always.

>
> ----------------------------------------------------------------------------
> > > - accessing one character in a string.
> >
> > >   s[3] does not do what most programmers would expect:
> > >     it returns a *number*. JavaScript is cleaner in this thing - there
> > >     are both .charAt () and .charCodeAt (). IMHO s[n] should return the
> > >     character as a string of length one, not the value - but now it's
> > >     too late to change this. The current meaning is not bad, it's just
> > >     unusual.
> > >   s[3, 1] is to be used instead.

This is a good point.  Did you know that where you expect to write

  if string[3] == "e"

you can write

  if string[3] == ?e

or

  if string[3].chr == "e"

so all is not lost.

>
>
> ----------------------------------------------------------------------------
> > > - a %= b versus %=...=. A syntax highlighter gets into big trouble when
> > >   seeing this construct. Nothing really seriuos, but I already had to
> > >   insert "useless" comments to fix vim's highlighting - which is unable
> > >   to correctly highlight if-then-end expressions. Perhaps it would help
> > >   to deprecate %=...= as string separator (any other character could be
> > >   used with less problems).
> >

So use another character.

Cheers,
Gavin