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 -