On 29.05.2016, at 10:59, marcel.taeumel Marcel.Taeumel@hpi.de wrote:
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.
Only since recently. Still not sure it’s a good idea.
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?
This is exactly the reason we resisted adding Object>>value for a long time, because it hides errors. E.g. your use of {} in the otherwise-case, which is wrong. Each case should be evaluated only when the matching condition is true, hence the need to use a block. Arguably the compiler should warn about not using a block as argument to ‘otherwise:'.
Perhaps a more Smalltalky way could be added if allowed binary and unary messages to cascade:
number = 0 => [24]; = 1 => [42]; else => ['hi']
Btw this is how things worked in Smalltalk-76/78:
- Bert -
