SelectCase

Ramon Leon rleon at insario.com
Wed Jan 4 19:43:30 UTC 2006


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
> 
> 
> 



More information about the Squeak-dev mailing list