From: William Djaja Tjokroaminata Date: 2002-09-27T07:17:44+09:00 Subject: Re: Ruby - common pitfalls? Hi, ---------------------------------------------------------------------------- Rudolf Polzer 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! ---------------------------------------------------------------------------- > - 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 "="? Also, you know, the parentheses are really optional in the condition, independent of all other things. ---------------------------------------------------------------------------- > - 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. ---------------------------------------------------------------------------- > - 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?) ---------------------------------------------------------------------------- > 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. ---------------------------------------------------------------------------- > -- > [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? I really like the song. Right now I am following DragonBall Z :) Cheers, Bill