On Sun, 28 Mar 2021, Thiede, Christoph wrote:

> 
> Hi all,
> 
> 
> thanks for all the opinions! :-) 
> 
> 
> 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. :-)

I had a look at the change set. It looks good but seems to lack 
decompiler-related changes which I think are necessary to keep the 
decompiler working.


Levente

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