Hi all,


thanks for all the opinions! :-)

<http://www.hpi.de/>

I see that the general use of #caseOf:[otherwise:] is probably of matter of taste - personally, I like it to remove duplication. Kent Beck even recommends refactoring something like this:
aBoolean ifTrue: [^1] ifFalse: [^2]
to something like that:
^ aBoolean ifTrue: [1] ifFalse: [2]
So I have the feeling that he would also recommend refactoring
anInteger = 1 ifTrue: [^ #one].
anInteger = 2 ifTrue: [^ #two].
anInteger = 3 ifTrue: [^ #three].
^ self error
to:
anInteger caseOf: {
    [1] -> [#one].
    [2] -> [#two].
    [3] -> [#three] }
However, I don't know him personally, so this is an assumption only, of course. ;-)

@David: I find your thoughts about boring code interesting. My personal perspective is rather different, I always try to minimize duplication, but I have already been having many discussions about this with some fellow students, so probably, the best solution lies somewhere in the middle between boringness (Robert Martin) and deduplication (Kent Beck) ... :-)

> If you were to add #identityCaseOf:[otherwise:] to the protocol of Object, there is a risk that people would perceive it as a feature of the language, and as something that they should try to incorporate into their own code. That would not be a good thing.

Why not (except the reasons you listed above), if I may ask? :-) #caseOf:[otherwise:] already *is* part of the protocol of Object, and so are #yourself and #in:, too. IMHO they are kind of features of the language - not a syntactical way, thanks to Smalltalk minimalism, but still, they are understood by every object. Unless we deprecate them, we should indeed assume that people use them, of course.

@Tim:

> Far too like C.

Again, why please? :-) I'm not a big fan of C either, but IMO switch/select/case is not the worst concept when it allows you to eliminate some duplication. Still, I would not say #caseOf:[otherwise:] is the end goal in every case - often it helps you to identify data in your code, and a further refactoring step could be to extract the data into a separate method as a dictionary. See [1] for further thoughts about this.

@Levente: Glad you like it! Regarding arguments, did you read [2]? It's already a bit older but I have not continued working on this since I'm afraid have not got any feedback on the proposal. :-)

[1] https://twitter.com/LinqLover/status/1375191096658178050
[2] http://forum.world.st/Merge-Request-caseOf-otherwise-with-arguments-td5112223.html

Best,
Christoph
________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Levente Uzonyi <leves at caesar.elte.hu>
Gesendet: Sonntag, 28. März 2021 10:33:32
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #identityCaseOf:

Hi Christoph,

I see some value having #identityCaseOf:, so +1 from me.

But what would be a more interesting thing to explore (yes, I'm derailing
this conversation now because the answer to your question is yes already
:)) is to extend the functionality of #caseOf:.

For example, passing the object to the condition block (or even the result
block) could be useful:

self someComplexExpression caseOf: {
         [ 1 ] -> [ self success ]
         [ :value | value odd ] -> [ :value | self processEvenValue: value - 1 ].
         [ :value | true "it's even ] -> [ :value | self processEvenValue ] }

There are two new things in the example:
- the value of self someComplexExpression is optionally passed to the
blocks. Yes, that could be done by creating a temporary variable. The
compiler could do exactly that behind the scenes.
- when the value is passed to the matcher block, possibilities are greatly
extended. For example, it could even reproduce #identityCaseOf:

         foo caseOf: {
                 [ :o | o == #foo ] -> [ self foo ].
                 [ :o | o == #bar ] -> [ self bar ] }

The same thing could be done with the otherwise block too:

         self foo
                 caseOf: { ... }
                 otherwise: [ :value | value ]


Levente


On Sat, 27 Mar 2021, Thiede, Christoph wrote:

>
> Hi all,
>
>
> the proposal is in the title. :-) Do you think we could need something like #identityCaseOf:[otherwise:], analogously to #caseOf:[otherwise:], on Object?
>
>
> Here is my motivation: I very often use #caseOf:[otherwise:] to eliminate nested if blocks (for one of many examples, take a look at PreferenceBrowserMorph >> #keyPressed:). In one recent situation [1], however, I confused
> equality and identity (I have to admit that this is a common error of mines) so I had to convert my beautiful #caseOf: statement back to a boring list of if checks. I wonder whether we could - or should - introduce something
> like #identityCaseOf:otherwise: (names subjected to discussion) for such situations?
>
>
> Historically, I guess this has not been built because #caseOf: has probably been inspired by the switch/select/case statement of other languages, which usually only accept constant case values. But in Smalltalk, luckily, we
> do not have this restriction, thus I'm wondering whether there is any reason to have #caseOf: but not #identityCaseOf:. Looking forward to your opinions! :-)
>
>
> Best,
>
> Christoph
>
>
> [1] https://github.com/LinqLover/SimulationStudio/commit/ddf0ef3e21c63a2fd9b08703c8e9ff213b7b6b0b
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210328/34fdaccf/attachment.html>