A little disappointed so far

[Jay O'Connor]

On Mon, 19 May 2003 02:36:53 +0100, Graham Nicholls
<graham at rockcons.co.uk> wrote:


>Thanks again.  I'll be browsing for a while :-)

Your welcome.  The capabilities you want are all easy to do, but they
all come in modules you import so you have to read the modulae
documentation to learn about them


>> Actually, from a Smalltalk pure OO background I find that case
>> statements are superflous in OO languages and had been programming
>> Python for about 8 months before I even wondered if the language had
>> them :)
>>
>How do you handle, say 
>if arg == 'd':
>        switch on debug
>if arg == 'v':
>        switch on verbose
>        
>etc ? 

Well...it a very simple case, probably a lot like that but with a
break to not have to test each condition :) 

if arg =='d':
	debug = 1
	break
if arg == 'v': 
	verbose = 1
	break

etc...


However, back to my real point...

>From one level, in an OO sense, a case statement is really testing the
state of one object, and then performing some operation.  Well, from
an OO point of view, if you are testing another object to do
something, might as well just give that responsibility to the other
object and allow polymorphism  to handle the particulars.  For
example, rather than testing a shape if it is a cricle, and then
drawing a circle, or a square, etc...yuo simple call 'draw()' on the
shape and let polymorphism handle that the correct version of draw()
for cicles, squares, etc.. is called (I acn post a code exmple if you
would like).  An often used part of this a technique called double
dispatch (where when you call to the object, in a general way, it
calls back to you in a specify way..again I can provide a code
example)

So, from a 'proper OO' perspective, for the most part, cases
statements are superflous and actually not to be desired as you are
not properly distributing responsibilites to the right objects.  As a
matter of fact, I'm not a big fan of long is statements for the same
reason.

This works for most situations. Testing characters is kinda a
pathological case in that characters are not normally real objects
that can be distinguished with polymorphism.  From 


For simple cases, I'd probably do like above.  It's not really that
much worse than 

	case (arg)
		switch ('d') {
			debug = 1;
			break}
		switch ('v") {
			verbose = 1;
			break

or similar.

For more complicated situations, I'd probably use some sort of
dictionary dispatch mechanism.  Here's one isuing a dictionary keyed
off of the arg with the values as references to functions defined
earlier.

def cased():
	#do lost of stuff here

def casev():
	#do lots of stuff here


cases = {'d":cased,
		'v':casev}

case = cases(arg)  # llookup what function to call
case()				# call it

You could do something similar with class methods in a Case class


Again, it really depends in the level of complexity.  In any more
complex logic, I find using other OO tools such as polymorphism to be
more powerful in the long run.  For medium complexity tasks, I like to
use dictionaries where the key is what I am testing and the value
is..some mechanism that will do what I need.  For simple tasks and if
with break works fine.

Hope that helps.

Take care,
Jay