[Python-3000] upon

[Talin]

Antoine wrote:
>> However, this special-case approach is flawed in this example, because
>> its use is so narrow. If you think about it for a minute, you
>> immediately start to imagine all of the things that 'upon' ought to deal
>> with that it doesn't.
>> For example, it has no way to deal with error
>> callbacks;
> 
> Arguably you could write :
> 
>     # Create a callback timer
>     alarm = Timer()
>     alarm.SetDuration( 100, Timer.Milliseconds )
> 
>     upon alarm.success:
>        print "It's time to get up, silly-head!"
>     upon alarm.failure:
>        print "The clock is broken, you can go back to bed"
> 
> (or @upon(alarm.success) for the suggested decorator equivalent)
> 
> Which would resolve to something like :
> 
>     def _cb():
>        print "It's time to get up, silly-head!"
>     alarm.success.__upon__(_cb)
>     def _cb():
>        print "The clock is broken, you can go back to bed"
>     alarm.failure.__upon__(_cb)

Interesting. Very interesting.

You could even do a switch statement with this idea:

    # Create the dispatcher
    s = Switch()

    # Set up the cases
    upon s.case(1):
       ... code for case 1
    upon s.case(2):
       ... code for case 2
    upon s.case(3):
       ... code for case 3

    # Invoke the case corresponding to value 'n'
    s( n )

Where 'case' associates assigns the suite to a dictionary, using the 
argument (1, 2, ...) as the key. Once the case handlers are set up, you 
can invoke the 'switch' as many times as you want, without having to 
re-evaluate the case expressions. You can even pass the dispatcher 
around to other objects and invoke it remotely.

Hmmm, a single syntax that handles both async callbacks, async errors, 
and switch/case constructs...maybe this would be more useful than I 
thought ... :)

Now, can we figure out how to handle arguments to the code block...?

-- Talin