A little disappointed so far

[Graham Nicholls]

Jay O'Connor wrote:

> 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 :)
pedant! :-)
> 
> 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).  
If its not too much trouble...
> 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)
ditto...
> 
> 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
> 
Aha - thats exactly what I was hoping to be able to do in my arg handling,
and was disappointed that I couldn't - thanks !  Might be a bit verbose for
handling a simple debug/verbose switch, but in general is exactly what I
want.

> 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
Excellent, Thanks.

-- 
Graham Nicholls
All round good guy.