marcel.taeumel wrote
> Hi, there!
> 
> I cannot write this without the parser complaining:
> 
> number caseOf: {
>    0 -> 1.
>    1 -> 1.
> } otherwise: { ... }.
> 
> Because what I should write is this:
> 
> number caseOf: {
>   [0] -> [1].
>   [1] -> [1].
> } otherwise: { ... }.
> 
> I think that this is not for the parser to decide. Numbers do understand
> #value. Any object does. So this is fine. Am I missing something?
> 
> It reminds me of this mistake our students typically make at least once:
> 
> (someBooleanExpression) and: (someOtherBooleanExpression)
> versus
> (someBooleanExpression) and: [someOtherBooleanExpression]
> versus
> [someBooleanExpression] and: (someOtherBooleanExpression)
> versus
> [someBooleanExpression] and: [someOtherBooleanExpression]
> 
> Sure, we can offer tool support to help in such situations. But the parser
> is just too naggy. :-)
> 
> Best,
> Marcel

Okay, this was stoopid. ;o) I assumed an implicit comparison:

number caseOf: {
  [number = 0] -> [1].
  [number = 1] -> [1].
} otherwise: { ... }. 

Still, no need to force the result also into a block? Why not just modify
the implementation of #caseOf:otherwise: to make such comparisons if there
is no block given?

Goal: Avoid nested iftrue-iffalse calls. Is there something more
Smalltalk-ish? Or functional? Is there some pattern matching hidden
somewhere?

Best,
Marcel



--
View this message in context: http://forum.world.st/caseOf-otherwise-Parser-is-way-too-cautious-tp4897986p4897987.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.