GUI Frames and classmethod

[Scott David Daniels]

Zak Arntson wrote:
> On Mon, 06 Dec 2004 13:08:15 -0800, Scott David Daniels
> <scott.daniels at acm.org> wrote:
> 
>>Zak Arntson wrote:
>>
>>>On Fri, 03 Dec 2004 14:48:30 -0800, Scott David Daniels wrote:
>>...The real advantage is clarity: the inner dictionaries in a dict-of-dict
>>implementation have no real "meaning."  The extra overhead (in the mind
>>of the program reader) involved in creating inner dictionaries at
>>appropriate times makes the code harder to understand.
> 
> ... If I see:
> {("None", "Enter"): enter_state_None,
>  ("None", "During"): during_state_None,
>  ("None", "Leave"): leave_state_None,
>  ("LWait", "Enter"): enter_state_LWait,
>  ("LWait", "During"): during_state_LWait,
>  ("LWait", "Leave"): leave_state_LWait}
> 
> I want to split it up. This is more intuitive for me because it shows
> an obvious one-many relationship between the outer keys and the inner
> keys.
> {"None": {"Enter": enter_state_None, "During": during_state_None,
> "Leave": leave_state_None},
>  "LWait": {"Enter": enter_state_LWait, "During": during_state_Lwait,
> "Leave": leave_state_LWait}}
> 
First, I'd probably write the above as some variation of the following:
     {"None": {"Enter": enter_state_None,
               "During": during_state_None,
               "Leave": leave_state_None},
      "LWait": {"Enter": enter_state_LWait,
                "During": during_state_Lwait,
                "Leave": leave_state_LWait}
     }
to show the two-layer structure.  I'd also prefer function names
describing what is done, rather than why the code was called, but
the names may only be in the current form because we are talking
about coding, and have no real application here.

Second, I was referring to code like:

      try:
          inner = table[state]
      except KeyError:
          table[state] = inner = {}
      inner[action] = whatever

vs. code like this:

      table[state, action] = whatever

That is, dynamic table modification code for a table of pairs is
clearer.  If you are simply creating the table from a simple source,
I might make a different choice.  I am not particularly big on
names like enter_state_none, nor one of prescribing a structure
that makes the creation of lots of no-ops necessary.  I'd rather
see code using the system look like:

     try:
         action = table[state, stimulus]
     except KeyError:
         pass
     else:
         action(arglist)

or even:

     def noop(*args, **kwargs):
         pass
     ...
     table.get((state, stimulus), noop)(arglist)


If each state is an instance with a dictionary, you might even want
to go with:
     class State(object): pass # or whatever
     ...
     NullState = State()
     NullState.enter = whatever
     NullState.during = whenever
     NullState.leave = forever


--Scott David Daniels
Scott.Daniels at acm.org