From: Rudolf Polzer Date: 2002-09-27T07:58:07+09:00 Subject: Re: Ruby - common pitfalls? Scripsit ille William Djaja Tjokroaminata : > 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! 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? Sou da. > 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 f�rchteten die Dunkelheit, vertrieben sie mit Feuer... [Rei in NGE, #11]