sytnax

[Shai Rosenfeld]

syntax question:

i have a 'case' expression:


case number
when 1: var = 'one'
when 2: var = 'two'
when 3: var = 'three'
else
var = 'else'
end


but instead of assigning the 'var' variable for each 'when', what is the
way to write the case statement, so i can assign 'var' at the end?

(something like

case number
when 1: 'one'
when 2: 'two'
when 3: 'three'
else
'else'
end >> var

[humm, a more elegant way]

)

 

[Sebastian Hungerecker]

case number
when 1: var = 'one'
when 2: var = 'two'
when 3: var = 'three'
else
var = 'else'
end


but instead of assigning the 'var' variable for each 'when', what is the
way to write the case statement, so i can assign 'var' at the end?

var=case number
...
end


HTH,
Sebastian

 

[Tom Link]

case number

when 1: 'one'
when 2: 'two'
when 3: 'three'
else
'else'
end >> var

var = case ...

 

[Shai Rosenfeld]

..quick reply (didn't last a minute)


thanks.

 

[Phlip]

..quick reply (didn't last a minute)


thanks.

Or...

var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')

 

[Shai Rosenfeld]

Or...

var = { 1 => 'one', 2 => 'two', 3 => 'three' }.fetch(number, 'else')

nice!

any lead to which one is faster?

 

[Phlip]

nice!

any lead to which one is faster?

D'OH!

(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)

 

[dblack]

Hi --

nice!

any lead to which one is faster?

Some quick benchmarking suggests that for small numbers of items
they're about equal, but the case one slows down faster as the number
of choices increases, presumably because it has to do a comparison for
each one instead of just one hash fetch.

It would also depend on which one matched, though -- for example:

case 1
when 1 then "one"
when 2 then "two"
...
when 1000000 then "one million"
end

will match on the first comparison, so it doesn't matter that there
are a million of them.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[dblack]

Hi --

D'OH!

(There was just a big discussion on Ruby performance, or lack thereof.
Google "Performance diffrence between ifs and case", and learn A>
premature optimization is the root of all evil, and B> you can profile
each system with unit tests and Benchmark library.)

Not all optimization is premature, and it's not the case that no
information is available to people before they start to code
something, or even just out of academic or scientific interest quite
apart from any particular coding project.

There's a long history of quite interesting discussion about
performance on this list, often involving benchmark reports (and
therefore explicitly in the knowledge of the relevance of the
benchmarking process). Those discussions can be very illuminating,
and I'd prefer not to see them routinely squashed before they have a
chance to start.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)

 

[Alex Young]

Hi --



Not all optimization is premature, and it's not the case that no
information is available to people before they start to code
something, or even just out of academic or scientific interest quite
apart from any particular coding project.

There's a long history of quite interesting discussion about
performance on this list, often involving benchmark reports (and
therefore explicitly in the knowledge of the relevance of the
benchmarking process). Those discussions can be very illuminating,
and I'd prefer not to see them routinely squashed before they have a
chance to start.

They're only going to get more interesting in future, as we have more
different implementations to play with, too...