Or, using registered objects for each key handler, something like:

(self keyHandlers detect: [:ea | ea wantsKey: keyPressed] ifNone: [])
	ifNotNilDo: [:handler | handler handleKey: keyPressed]

Or you could use a #select: if you want all the handlers to have a 
chance to act.

Ramon Leon wrote:
> How about...
> 
> (Dictionary new)
>     at: $c put: [self copy];
>     at: $x put: [self cut];
>     at: $v put: [self paste];
>     at: keyPressed ifAbsent:[].
> 
> 
>>-----Original Message-----
>>From: squeak-dev-bounces at lists.squeakfoundation.org 
>>[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
>>Behalf Of Chris Muller
>>Sent: Wednesday, January 04, 2006 12:29 PM
>>To: squeak-dev at lists.squeakfoundation.org
>>Subject: Re: SelectCase
>>
>>I agree with your sentiments, but then I came across one case 
>>(after ten years!) where, to my shock-and-awe (tm), case 
>>seemed appropriate.  I'm interested in what you think a good 
>>alternative might be that also pays for its weight..
>>
>>A key-command handler method.
>>
>>  keyPressed caseOf:
>>    {[$c]->[self copy].
>>    [$x]->[self cut].
>>    [$v]->[self paste]}
>>
>>What's the best way other than case statement to map 
>>keyPressed to the desired action?
>>
>>Regards..
>>
>>
>>>Message: 24
>>>Date: Wed, 04 Jan 2006 03:38:39 -0800
>>>From: Andreas Raab <andreas.raab at gmx.de>
>>>Subject: Re: SelectCase
>>>To: The general-purpose Squeak developers list
>>>	<squeak-dev at lists.squeakfoundation.org>
>>>Message-ID: <43BBB3BF.70801 at gmx.de>
>>>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>
>>>Ragnar Hojland Espinosa wrote:
>>>
>>>>>I know select/case statements is not desired in
>>>
>>>the squeak community
>>>
>>>>>and I understand why (it's often a wrong
>>>
>>>modelisation). But I put
>>>
>>>>>an implementation in squeaksource which can be
>>>
>>>used like this :
>>>
>>>>>(aString selectCase )
>>>>>       testBlock: [:ref :case | case match: ref];
>>>>>       case: 't*' exec: [self assert: false];
>>>>>       case: 'v*' exec: [self assert: true];
>>>>>       case: 'value' exec: [self assert: false];
>>>>>       default: [^ nil]
>>>>>
>>>>>#testBlock: and #default: can be ommited.
>>>>
>>>>What's wrong with
>>>>
>>>
>>http://wiki.cs.uiuc.edu/CampSmalltalk/Smalltalk+case-statement
>>
>>>?
>>>
>>>Nothing. I think it sucks just about as much as the above 
>>
>>;-) And, oh, 
>>
>>>did you know that Squeak has had a case statement for ages? 
>>
>>I've never 
>>
>>>seen it used in any code but, in theory, it works like this:
>>>
>>>	aString caseOf: {
>>>		['foo'] -> [self foo].
>>>		['bar'] -> [self bar].
>>>	} otherwise:[self frobler].
>>>
>>>And there is nothing wrong with this either, and yes, it 
>>
>>sucks just as 
>>
>>>much as the other variants ;-) And just in case you haven't guessed 
>>>it:
>>>"Classic" case statements (those based purely on
>>>equality) can *always*
>>>be represented by a simple dictionary lookup, e.g, instead of the 
>>>above you might as well write:
>>>
>>>	map := Dictionary new.
>>>	map at: 'foo' put: [self foo].
>>>	map at: 'bar' put: [self bar].
>>>	elseBlock := [self mumble].
>>>	result := (map at: aString ifAbsent:[elseBlock]) value.
>>>
>>>and if you don't like that, stick the map into a class var 
>>
>>and replace 
>>
>>>it with something roughly equivalent to:
>>>
>>>	^(SwitchMap at: aString ifAbsent:[whatever]) value.
>>>
>>>In any case, I doubt the existence of YACI (yet another case
>>>implementation) will change much. It's bad style to begin with and 
>>>it's easy enough (actually trivial) to simulate by using 
>>
>>objects. The 
>>
>>>one case implementation I'd really like is one that 
>>
>>actually *reads* 
>>
>>>well (e.g., one that doesn't look like reverse polish
>>>notation) but for
>>>obvious reasons that would require quite a bit of compiler support.
>>>
>>>Cheers,
>>>   - Andreas
>>
>>
>>
>