switch

[Tim Chase]

On 12/10/2009 09:22 PM, John Bokma wrote:
> Tim Chase<python.list at tim.thechases.com>  writes:
>
> Please don't delete attribution line(s), added:
>
>     Asun Friere writes:

I tend to prune them because a good newsreader will thread 
messages and put my reply in the context of the message to which 
I'm replying.  Both Thunderbird and Claws Mail seem to have 
correctly placed my message under Asun's message.  However your 
reply to mine failed to show up under my message in either 
program (it showed up under the top-level post by Hong Zhang in 
both apps).  Looks like you're sending from Gnus...a 
threading/reply bug in Gnus perhaps?  Anyways...I'll leave them 
in for this reply.

>>>           phone.update_from_record(record)
>>>
>>> This switch statement belongs to one guy.  One guy who wants to know
>>> how to do everything that needs to be done to Phones no matter who
>>> asks
>>
>> This is where you make a false assumption -- the contents and parsing
>> of the "switch" are provider-specific in this case, mapping to a
>> common ontology of the Phone object:
>
> In that case, why not give the classes Asun suggested all the same base
> class: Phone?

Whether the logic gets put in a subclass of Phone, or whether it 
gets put in a provider Phone-factory (as it currently does...the 
Provider superclass also knows how to auto-detect the format of a 
filename/path passed to it and know whether it can handle it), 
there's still a rat's-nest of if/else/switch type logic, each 
branch of which usually involves a single assignment, or further 
sub-branch checking.  So I often have things that would 
pseudo-code like

   switch rectype:
     case '01':
       phone.textmessaging += row['txtmsgcost']
       count = row['count']
       switch subtype:
         case 'a': phone.textmessagessent += count
         case 'b': phone.textmessagesreceived += count
         case 'c': phone.pagessent += count
         case 'd': phone.pagesreceived += count
     case '02':
       ...

which is fairly readable.  However, with a method-dispatch 
dictionary, this flattens the hierarchy to "def"s at the same 
level (class definition scope), leaving the hierarchy visible 
only in the call-graph.

Turning each of these a function would

- obfuscate the flow and processing hierarchy
- create a profusion of 1-3 line functions (about 50 Phone 
attributes, times currently about 15 provider formats, plus a 
duplication factor of about 10% where certain fields aggregate 
from various sources in the data, accumulating in a single Phone 
field)
- have the overhead of several million function-calls

>> Yes, having been programming since I was in middle-school (quick
>> calculation yields a "boy I'm old" estimate of about 20 years...does
>> anybody miss 360k 5.25" floppy disks? :)
>
> I do miss cassette tapes and the wheeeeeee kkkrggrggrgrgrg of a program
> loading.

Heh, one of the other things I miss:  booting my Apple ][+ and 
hitting the <Reset> button, resulting in a prompt where I could 
code in under 2 seconds from power-on.  Can't say I miss tape at 
all though :)

-tkc