[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

case when...

Josselin

1/5/2007 2:59:00 PM

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
64 Answers

Carlos

1/5/2007 3:07:00 PM

0

Josselin wrote:

> 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

Try it!
--



Josselin

1/5/2007 3:53:00 PM

0

On 2007-01-05 16:07:15 +0100, Carlos <angus@quovadis.com.ar> said:

> Josselin wrote:
>
>> 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
>
> Try it!

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

got it...

Jacob Fugal

1/5/2007 4:55:00 PM

0

On 1/5/07, Josselin <josselin@wanadoo.fr> wrote:
> >> case 'a'
> >> when 'a1'
> >> puts..
> >> puts ...
> >> return
> >> when 'a2'
> >> puts ...
> >> puts ...
> >> puts ...
> >> return
> >> 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 Fugal

greg.kujawa

1/5/2007 5:07:00 PM

0

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.

Jacob Fugal wrote:
> On 1/5/07, Josselin <josselin@wanadoo.fr> wrote:
> > >> case 'a'
> > >> when 'a1'
> > >> puts..
> > >> puts ...
> > >> return
> > >> when 'a2'
> > >> puts ...
> > >> puts ...
> > >> puts ...
> > >> return
> > >> 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 Fugal

James Gray

1/5/2007 5:18:00 PM

0

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.co...
replaceConditionalWithPolymorphism.html

James Edward Gray II

greg.kujawa

1/5/2007 5:25:00 PM

0

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 Edward Gray II wrote:
> 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.co...
> replaceConditionalWithPolymorphism.html
>
> James Edward Gray II

Josselin

1/5/2007 5:38:00 PM

0

On 2007-01-05 18:25:03 +0100, "gregarican" <greg.kujawa@gmail.com> said:

> 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 Edward Gray II wrote:
>> 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.co...
>> replaceConditionalWithPolymorphism.html
>>
>> James Edward Gray 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

James Gray

1/5/2007 5:48:00 PM

0

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 Gray II

Jano Svitok

1/5/2007 9:50:00 PM

0

On 1/5/07, James Edward Gray II <james@grayproductions.net> wrote:
> 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 Gray 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).

James Gray

1/5/2007 10:01:00 PM

0

On Jan 5, 2007, at 3:49 PM, Jan Svitok wrote:

> On 1/5/07, James Edward Gray II <james@grayproductions.net> wrote:
>> 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 Gray 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).

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 Gray II