elseif v. elsif ??

[Pit Capitain]

(...)
If I run the following code, I don't get any errors:

class MegaGreeter
attr_accessor :names

#constructor
def initialize(names = "world")
@names = names
end

#functions:
def say_hi
if @names.nil?
puts "..."
elseif @names.respond_to?("each")
@names.each do |name|
puts "Hello #{name}!"
end
else
puts "Hello #{@names}!"
end
end
end
if __FILE__ == $0
mg = MegaGreeter.new(["Sally", "Jane", "Bob"])
mg.say_hi
end

Hi 7stud,

when reading (compiling) your code, Ruby can only detect syntactic
errors, and your code is syntactically correct. Other errors can only be
determined at run time. Let me show you...

You get an error when you try your code with another instance:

mg2 = MegaGreeter.new(nil)
mg2.say_hi

Output:

...
in `say_hi': undefined method `elseif' (NoMethodError)

This error message shows that Ruby tried to execute the method #elseif,
which obviously isn't defined. Ruby cannot decide in advance whether
there will be an error or not:

mg3 = MegaGreeter.new(nil)

def mg3.elseif(arg)
puts "Hello from elseif with arg #{arg}"
end

mg3.say_hi

This code defines the method #elseif for the object mg3. The output is:

...
Hello from elseif with arg false
in `say_hi': undefined method `each' for nil:NilClass (NoMethodError)

You can see that the #elseif method is called, but then there's an error
in the next line: because @names is nil in this case, we call the method
#each on the object nil, which isn't defined.

I should have said: normally it isn't defined. We can change this:

def nil.each
yield "nil"
end

mg3.say_hi

This code defines the method #each for the object nil, so that it passes
the string "nil" to the block. The output is:

...
Hello from elseif with arg true
Hello nil!

You can see that your code executes fine in this case. This can only be
determined by actually running the code. Ruby is very dynamic, which
sometimes isn't an advantage, as has been in your case. But it can be a
very powerful tool, which is why we all hang out here.

Regards,
Pit

 

[7stud 7stud]

Add some spaces at the front of the 'elseif' line, so that it aligns

with
the 'puts "..."' on the line above. Then you'll see how Ruby is
interpreting
your code.

Unlike python, Ruby doesn't *force* you to align your source in a
particular
way.

Ok, thanks.

 

[Robert Dober]

Another question. The tutorial says:


and at the top of the file is the shebang:

#!/usr/bin/env ruby

If you run the program using 'ruby filename', do you need the shebang? That is correct
I read something that said you only need the shebang if you want to
execute programs using just the filename, e.g.:

$ HelloWorld.rb exactly

also what does 'env' do? I read the man pages on the env function, and
I can't figure out what it does in the shebang.

It runs a program in a modified environment, it is frequently used in
the shebang because it is normally in a standard location while ruby
itself might be in
different locations e.g. /usr/bin or /usr/local/bin.
It is a trick to get this information from the "environment".
But is is not always a good idea, try

#!/usr/bin/env ruby -w

it does not work -w is interpreted by env not by ruby
Robert

 

[7stud 7stud]

Thanks for all the help. It looks like way up at the top, Robert Dober
first identified the problem, but I didn't see how it applied.

As a newcomer, I would suggest someone redo the tutorial "Ruby in 20
Minutes": add in 'then' and include a statement about 'elsif v. elseif'.
I still think leaving the 'e' out is a ridiculous construct.

 

[Pit Capitain]

I still think leaving the 'e' out is a ridiculous construct.

It all depends where you come from. Other languages have had elsif
before Ruby:

Ada
Perl
PL/SQL
PostgreSQL

Just to name a few.

Regards,
Pit

 

[Chad Perrin]

To me 'elif' stands out like a red flag. 'elsif' is a more subtle
differentiation, and I couldn't spot it even though I had the problem
narrowed down to 3 lines of code. The "Ruby in 20 Minutes" tutorial is
obviously geared to the experienced programmer(beginner's don't know
what classes are or what an 'attr_accessor' is), so I would suggest
putting this in the tutorial:

LOOK AT THE ELSIF SYNTAX CAREFULLY--IT'S 'ELSIF' NOT 'ELSEIF'

with the 'E' in elseif in red.

Really, your complaint amounts to nothing more than "I'm more used to
the way language A does it than the way language B does it -- so
language B must be wrong."

Technically speaking, "elseif", "elsif", and "elif" are equally "wrong".
To do it right, you'd have to make it "else if".

 

[David A. Black]

Hi --

Does Ruby try differentiate itself in ridiculous ways like that just for
the sake of being different?

No -- literally never.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Robert Dober]

Really, your complaint amounts to nothing more than "I'm more used to
the way language A does it than the way language B does it -- so
language B must be wrong."

Technically speaking, "elseif", "elsif", and "elif" are equally "wrong".
To do it right, you'd have to make it "else if".

Chad you remind me of a dispute between fans of Domingo and Pavarotti when
a spanish music magazin explained that such discussions are futile and
nobody can judge at that level. This explaination took a whole article
just in concluding that Carreras was better than both...

So why would "else if" be better?

Cheers
Robert

 

[Jenda Krynicky]

Hi --



No -- literally never.


David

Yeah. Like the use of "throw" and "catch"; ".inject"; "yieieild" that's
not really the yield of coroutines, but just a way to call the unnamed
closure (or the unnamed unnamed function) that was passed to the method
as the last parameter; the fact that "and" and "or" have the same
precedence, while && has bigger precedence than ||, etc. etc. etc.

The fact that I'm supposed to write

puts 1 + 2 +
3

or

puts 1 + 2 \
+ 3

(Visual Basic anyone?) it fairly ... wuby as well.

 

[7stud 7stud]

Really, your complaint amounts to nothing more than "I'm more used to
the way language A does it than the way language B does it -- so
language B must be wrong."

Technically speaking, "elseif", "elsif", and "elif" are equally "wrong".
To do it right, you'd have to make it "else if".

Yes, I guess you're right. I've never seen 'elsif' or 'elif' before.
But couldn't/shouldn't that be expected? So why not point that out in
"Ruby in 20 Minutes"? There isn't even anything about that in the
"Ruby from C and C++" page either, although instead of burying it in
there, I suggest it be deployed to the front lines.

 

[7stud 7stud]

Also, to be consistent, shouldn't it be:

z = if x < y
true
els
false
end

 

[Martin DeMello]

Also, to be consistent, shouldn't it be:

z = if x < y
true
els
false
end

Note the difference between

z = if x < y
-1
else if x == y
0
else if x < y
1
end
end
end

and

z = if x < y
-1
elsif x == y
0
elsif x < y
1
end

martin

 

[7stud 7stud]

I strongly advice you to use a syntax highlighting ediotr like e.g.

vim, emacs, Jedit, geany and tons of others.

How do you turn on syntax highlighting with vim?

IM - Vi IMproved
~
~ version 6.2

 

[Sebastian Hungerecker]

How do you turn on syntax highlighting with vim?

:syntax on

 

[Robert Dober]

Note the difference between

z = if x < y
-1
else if x == y
0
else if x < y
1
end
end
end

and

z = if x < y
-1
elsif x == y
0
elsif x < y
1
end

martin

Thank you Martin, I started to feel lonely
R

 

[Avdi Grimm]

For the record, I find a few of Ruby's naming choices silly and
non-intuitive as well. "elsif", regardless of it's language lineage,
IS kinda weird and easy to miss. "case" should have been "switch".
And almost any of the proposed alternatives to "inject" would be
preferable - with my personal preferance being "fold".

But I'm so used to dealing with language eccentricities, and Ruby's
features give me so much joy, that it's easy to overlook such
nitpicks.

 

[John Joyce]

No.
Programming languages are, like all languages, arbitrary symbolic
sets based on some sort of logical meaning.
In this case, someone else's (els') logic.
Like human languages, it does little good to complain about idioms or
grammar, just use it.
Life is much easier then. Every programming language has differences,
sometimes small subtle ones. The small subtle things are what make C
and C++ difficult to debug. This is why we have tools like colored
text editors and lexical analyzers and debuggers. Arguably, a
computer language should be more like a human language, but that too
is a bad idea. Human language is very implicit, contextual, and
fuzzy. When you are really dealing with 1s and 0s you can't be so fuzzy.

 

[Brian Adkins]

What the?? I just spent two days trying to figure out why I couldn't
reproduce the example in "Ruby in 20 minutes" and get it to work. After
examining my code line for line against the example code and not being
able to detect any error, I was assembling several code examples into a
text file to post here, when I happened to notice 'elsif'. Why
didn't Ruby flag 'elseif' as an error?


Does Ruby try differentiate itself in ridiculous ways like that just for
the sake of being different? And why isn't something like that
explicitly pointed out in a beginning tutorial? So far, I have to give
Ruby two thumbs down.

C++, Java, Javascript, php, Servlets+JSP programmer

I have a similar language background (minus php). When I first looked at
Ruby, I spent a few minutes flipping through the Pickaxe, spotted what I
felt were some "Perlisms", and made a knee jerk reaction to reject the
language. I've since talked to a few folks who did the same, so mine was
not an isolated incident.

It was about a year later that I came back to Ruby (because of Rails)
and discovered that I like the language (a lot). I'm sharing this
because learning from other people's experience can be helpful. I don't
know if you'll end up enjoying the language as much as I have, but it
may be worthwhile to invest some more time with it before deciding. I
even realized that I actually like a few of the "Perlisms" - the horror!

 

[7stud 7stud]

:syntax on

Hey, I can see the elseif error now.

 

[Jenda Krynicky]

I have a similar language background (minus php). When I first looked at
Ruby, I spent a few minutes flipping through the Pickaxe, spotted what I
felt were some "Perlisms", and made a knee jerk reaction to reject the
language. I've since talked to a few folks who did the same, so mine was
not an isolated incident.

It was about a year later that I came back to Ruby (because of Rails)
and discovered that I like the language (a lot). I'm sharing this
because learning from other people's experience can be helpful. I don't
know if you'll end up enjoying the language as much as I have, but it
may be worthwhile to invest some more time with it before deciding. I
even realized that I actually like a few of the "Perlisms" - the horror!

Don't worry. They'll go away. The Wuby moto is break what works, rename
what's commonly known and add gotchas for fun.

Jenda