Forum: Ruby case when...

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Josselin (Guest)
on 2007-01-06 20:18
(Received via mailing list)
In all  examples I can see in my book about 'case ..' 'when..' 'then.. '
there is only one statement after the 'when..'  I understand using
'then' if the statement is on the same line as 'when', BUT
can I write multiple statements after the 'when' ?

like that :

case 'a'
  when 'a1'
    puts..
    puts ...
  return
  when 'a2'
    puts ...
    puts ...
    puts ...
  return
  when 'a3'  then puts ...
  else
    puts ...
    puts  ...
end

thansk fyh
Carlos (Guest)
on 2007-01-06 20:31
(Received via mailing list)
Josselin wrote:

>         puts ...
> end
Try it!
Josselin (Guest)
on 2007-01-19 17:29
(Received via mailing list)
On 2007-01-05 16:07:15 +0100, Carlos <removed_email_address@domain.invalid> 
said:

>>     when 'a1'
>>         puts ...
>>         puts  ...
>> end
>
> Try it!

a return was missing to close the latest 'else'....

got it...
Jacob F. (Guest)
on 2007-09-26 00:29
(Received via mailing list)
On 1/5/07, Josselin <removed_email_address@domain.invalid> wrote:
> >>     when 'a3'  then puts ...
> >>     else
> >>         puts ...
> >>         puts  ...
> >> end
>
> a return was missing to close the latest 'else'....

Huh? You don't need returns to "close" the when's or else. Unlike C,
there's no "trickle" effect to Ruby case statements, one a branch has
been matched, only that branch is executed. There's no need for
"break" or "return" or anything like that.

Jacob F.
James G. (Guest)
on 2007-09-26 00:30
(Received via mailing list)
On Jan 5, 2007, at 3:49 PM, Jan S. wrote:

>> class AccountController < ApplicationController
>>    def confirm_for_button_one_name
>> Just a thought.  Not that there is anything wrong with your case
> Then I was thinking that if the params[:submit_button] contained the
> whole method name, the confim method would be nicer. The drawback is
> that the way it is now  provides a bit of security -- it's not
> possible to call any method, just a limited subset. It would be
> possible to check whether the param is in a specified set, but that
> would break extensibility (or a means to extend the set would be
> needed).

It's just one thought.  There are times when it is very powerful
(like when building state machines), but this probably isn't one of
them and there is nothing wrong with using a case statement here, in
my opinion.

James Edward G. II
Josselin (Guest)
on 2007-09-26 00:38
(Received via mailing list)
On 2007-01-05 18:25:03 +0100, "gregarican" 
<removed_email_address@domain.invalid> said:

>>> Personally I like to adopt the old Smalltalk philosophy, where they
>> http://www.refactoring.com/catalog/
>> replaceConditionalWithPolymorphism.html
>>
>> James Edward G. II

thanks a lot for the link...   I'll read taht tonight !

I have to understand how to avoid   'if.. '  and 'case..'  to check
mulitple 'submit buttons from my form...

 I have an account_controller object ..  when the  user 'submit the
form, the 'confirm' method is called, but 2 buttons can confirm
so I have to check upon the submit value... which I do
each submit button CANNOT call a different method in my object..
...
I understand your concerns with OO programming approach, but who can
illustrate this approach on such simple problem...

joss
Jan S. (Guest)
on 2007-09-26 00:42
(Received via mailing list)
On 1/5/07, James Edward G. II <removed_email_address@domain.invalid> wrote:
>    # ...
>      # ... whatever ...
> statement though.
>
> James Edward G. II

I wanted to write that this is not a good example -- the case
statement would be more readable and probably even faster. Then I
realized that the situation changes if somebody wants to subclass this
and add another button. Just add another method and it's done. With
the case statement it wouldn't be that easy.

Then I was thinking that if the params[:submit_button] contained the
whole method name, the confim method would be nicer. The drawback is
that the way it is now  provides a bit of security -- it's not
possible to call any method, just a limited subset. It would be
possible to check whether the param is in a specified set, but that
would break extensibility (or a means to extend the set would be
needed).
Greg K. (Guest)
on 2007-09-26 00:44
(Received via mailing list)
Personally I like to adopt the old Smalltalk philosophy, where they
don't even use case statements. Since over time these can grow long and
ungainly you can take a different programming approach. It's a bit of a
mind stretch depending on where you're coming from, but it is good
practice. I think there's an older book called Smalltalk Best Practice
Patterns that touches on this. A good read, even if you don't ever
write a lick of Smalltalk. It's solid OOP approaches you can apply to
Ruby and other OOP languages.
Greg K. (Guest)
on 2007-09-26 00:45
(Received via mailing list)
Good point. All of it makes for good mental exercise and ultimately
more effective and efficient development. Rather than run something
through a bunch of conditionals, just pass along an overridden message
like 'processYourself' and let the object do the work. Depending on
what the object is receiving the message it can choose its own way of
doing things.
James G. (Guest)
on 2007-09-26 00:46
(Received via mailing list)
On Jan 5, 2007, at 11:40 AM, Josselin wrote:

> I have an account_controller object ..  when the  user 'submit the
> form, the 'confirm' method is called, but 2 buttons can confirm
> so I have to check upon the submit value... which I do
> each submit button CANNOT call a different method in my object..

Are you sure about that?  ;)

class AccountController < ApplicationController
   # ...

   def confirm
     send("confirm_for_#{params[:submit_button]}")
   end

   # ...

   private

   def confirm_for_button_one_name
     # ... whatever ...
   end

   def confirm_for_button_two_name
     # ... whatever ...
   end

   # ...
end

Just a thought.  Not that there is anything wrong with your case
statement though.

James Edward G. II
James G. (Guest)
on 2007-09-26 00:47
(Received via mailing list)
On Jan 5, 2007, at 11:10 AM, gregarican wrote:

> Personally I like to adopt the old Smalltalk philosophy, where they
> don't even use case statements. Since over time these can grow long
> and
> ungainly you can take a different programming approach. It's a bit
> of a
> mind stretch depending on where you're coming from, but it is good
> practice. I think there's an older book called Smalltalk Best Practice
> Patterns that touches on this.

It's also a "code smell" according to the classic Refactoring text:

http://www.refactoring.com/catalog/
replaceConditionalWithPolymorphism.html

James Edward G. II
This topic is locked and can not be replied to.