Hi andreas

Happy new year. I hope to see lot of release Tweak, Croquet, Sophie  
and more.

With ages I started to be less aggressive on my state statements.
But I really enjoy your style :) You reconcilate me with my own  
abrupt statements.
I thought I was the only one to hate caseOf statements in Squeak.

By the way seriously would it make sense to try to remove that this  
from Squeak.

Stef


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