Re: Ruby - common pitfalls?

Scripsit ille William Djaja Tjokroaminata <[e-mail]>:
> Hi,
> ----------------------------------------------------------------------------
> Rudolf Polzer <[e-mail]> wrote:
> > Is there a list of common pitfalls beginners in this language should
> > watch out for? I noticed (I just started with Ruby and it has almost
> > replaced Perl):
> 
> I just offered my service to start compiling "Things That Newcomers to
> Ruby Should Know" yesterday.  Yours will be my first entries.  Welcome!

Thanks.

> ----------------------------------------------------------------------------
> > - the if syntax. Pascal-style if is supported (and one is tempted to use
> >   it instead of the also supported C-style if since parantheses aren't
> >   easy to enter on most keyboards), but comparisons have to be written
> >   in C style. Therefore this happened to me more than once:
> 
> >     if foo = nil then
> >       # ...
> >     end
> 
> >   It's getting even worse because nil is named 'nil', like it is in
> >   Pascal.
> 
> >   The C-style syntax is:
> 
> >     if (foo == nil)
> >       # ...
> >     end
> 
> >   and works perfectly. If only ( and ) were accessible without using the
> >   shift key...
> 
> I am sorry, I am not clear about this.  In the "if foo = nil then", is the
> problem the "then" or the "="?

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.

> ----------------------------------------------------------------------------
> > - 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.
> 
> Perfectly valid concern.  I was also tripped by this a long time ago.  It
> took me a while to find the source of the problem.

Oh, in my "trap" it was relatively easy. I added the result to another
string and got an error since Ruby didn't want to make a String of a
Fixnum. Good that Ruby does not do such automatic conversions.

> ----------------------------------------------------------------------------
> > - 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).
> 
> I am sorry, I am not clear about "%=...=".  (Maybe I am not a good 
> editor, after all?)

$ ruby -e 's = %=hello world=; p s;'
"hello world"
$ ruby -e 'x = 3; x %= 2; p x;'
1

I'm not sure if it is always clear which meaning is the correct one. A
syntax highlighter would have to know...

$ ruby -e 'x = 1; def x (s) p s; end; x %= 2; a = * 1'
$ ruby -e 'x = 1; def x (s) p s; end; x %- 2; a - * 1'
" 2; a "

Seems like Ruby interprets %= as 'operator%= (&a, b)' whenever possible
when looking to the left.

But how to tell this to a syntax highlighter? At least %=...= and the
other %#...# rules would need different highlighting rules.

> ----------------------------------------------------------------------------
> > BTW: what about this extension:
> 
> (deleted)
> 
> > which is a bit more verbose, but can be done with the current syntax.
> 
> > Another idea for the above thing: an ArithArray class that is nearly
> > identical to the normal Array with one exception: the arithmetic and
> > logical operators work element-wise with the original meaning (so even
> > == would return a new array of true or false values).
> 
> These are all suggestions.  I think you can implement the ArithArray class
> yourself easily in Ruby.

It can easily be done - I think it would be ideal to add zipWith to the
normal Array class and then derive ArithArray from it, implementing the
"new" operators using zipWith.

> ----------------------------------------------------------------------------
> > -- 
> > [mpg123d] Just playing: .../01 cruel angel's thesis - director's edit - -ayanami-.mp3
> 
> > Shinu no wa iya. Shinu no wa iya. Shinu no wa iya. Shinu no wa iya.
> >      [Asuka in Neon Genesis Evangelion - english: "I don't want to die",
> ----------------------------------------------------------------------------
> Hey, you like Neon Genesis Evangelion too?

<Gendou>Sou da.</Gendou>

> I really like the song.

Me too - but IMHO the original version is the best one.

What a coincidence that the random signature fitted to the current
playlist item...

> Right now I am following DragonBall Z :)

BTW, this reminds me of a kakasi problem I have in my kakasi-renamer
script (which should rename file names containing Japanese characters to
Roumaji-encoded ones). I've opened a new thread for that.


-- 
[mpg123d] Just playing: .../albums/shamrock/09 don't sigh.mp3

Menschen fchteten die Dunkelheit, vertrieben sie mit Feuer...
                                                      [Rei in NGE, #11]