<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi all!<div><br></div><div>#caseOf:(otherwise:) has its uses. I would probably rarely use it for lookup tables with less than 3-4 rows, especially when there is no reason to believe that the list will grow soon. But even then, I tend to use ad-hoc dictionaries for the lookup, which might be not-so-good for performance.</div><div><br></div><div>In my opinion, good examples for #caseOf:(otherwise:) include (but are not limited to):</div><div><br></div><div>PNMReadWriter >> #nextImage</div><div>CompiledCode >> #scanFor:</div><div>Character >> #isSeparator</div><div>Context >> #exceptionMessage</div><div>DoItFirst >> #keyFor:</div><div>HandMorph >> #processEvents</div><div>Inspector >> #inspectorKey:from:</div><div>ProcessBrowser >> #processListKey:from:</div><div>MimeConverter class >> #forEncoding:</div><div>WebUtils class >> #jsonDecode:</div><div><br></div><div>Well, not-so-good examples include (but are not limited to):</div><div><br></div><div>MenuMorph >> #handleFiltering:</div><div>Text >> #format:</div><div>CompiledMethod >> #scanForInstructionPattern:</div><div><br></div><div>There, I would opt for the good-ol' #ifTrue:ifFalse:. Or maybe an "extract method"-refactoring might improve the intend and readability of those.</div><div><br></div><div>Any change to #caseOf: MUST account for the Decompiler. Even the introduction of an #identityCaseOf:(otherwise:).</div><div><br></div><div>"true caseOf: { ... }" is an anti pattern. Please don't do that. :-)</div><div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 07.04.2021 20:13:45 schrieb Jakob Reschke <jakres+squeak@gmail.com>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">Having started out with Delphi, I do not mind caseOf:. But I more often wish for Lisp's cond. true caseOf: looks somehow strange and like a hack to me—just a feeling—though I admit it does make sense when I force myself to read it as English: "For the true case of the following, do..."<div><br></div><div>Regarding letting people choose their protocols, just make sure that Smalltalk does not end up being a write-only-for-me language like Perl. :-)</div><div>I think there has already been this discussion about how many shortcuts and utility methods should be in the language and which should rather stay out.<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 7. Apr. 2021 um 17:53 Uhr schrieb Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>>:<br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex;border-left: 1px solid rgb(204,204,204);padding-left: 1ex;min-width: 500px">
<div>
<div dir="ltr">
<div id="gmail-m_5516145102508754180x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: rgb(0,0,0);font-family: Calibri,Helvetica,sans-serif">
<p>Woah, I didn't know that this topic has been such a hot potato. :-)</p>
<div id="gmail-m_5516145102508754180x_Signature">
<div id="gmail-m_5516145102508754180x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: rgb(0,0,0);font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper">
<div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">
<div id="gmail-m_5516145102508754180x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="gmail-m_5516145102508754180x_divtagdefaultwrapper"><span style="font-family: Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="gmail-m_5516145102508754180x_Signature">
<div style="margin:0px"><span style="">
<div><font size="3" color="black"><span style="font-size: 12pt"><a href="http://www.hpi.de/" rel="noopener noreferrer" id="gmail-m_5516145102508754180LPNoLP" target="_blank"><font size="2"><span id="gmail-m_5516145102508754180LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</span></div>
</div>
</span></div>
</div>
</div>
</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody"><br>
</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">In my opinion, people can always abuse a (domain-specific) language to write bad code and you cannot really stop them from doing so by limiting the features of the language. Instead of banning a protocol, people
should understand *why* and *when* it is a bad idea to use them. #caseOf: & Co. can be used and can be abused, so I vote for keeping and legalizing it (otherwise we have to destroy every bread knife, too).</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">If we stigmatize #caseOf:, we could also stigmatize or even deprecate #isKindOf: because very often, it is abused - but still, it can be useful in many situations where you need metaprogramming indeed, for example,
Exception class >> #handles:.</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">LBNL, I often consider both concepts as the first step of a larger refactoring. Alone for this purpose, I would like to keep these selectors.</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody"><br>
</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">Best,</div>
<div id="gmail-m_5516145102508754180x_Item.MessagePartBody">Christoph</div>
</div>
<div><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_5516145102508754180x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von tim Rowledge <<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>><br>
<b>Gesendet:</b> Sonntag, 28. März 2021 19:07:58<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] #identityCaseOf:</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div><br>
<br>
> On 2021-03-28, at 4:09 AM, Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de" target="_blank">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br>
> <br>
> @Tim:<br>
> <br>
> > Far too like C.<br>
> <br>
> 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.
<br>
<br>
It (both C and caseOf*) has its uses but my practical issue with caseOf* in Smalltalk is that I keep (very subjective and personal experience dependant) seeing it get used in ways that completely sidestep Smalltalk and implement bad C idiom. A bit like isKindOf:
and isBlahClass.<br>
<br>
e.g.<br>
foo class<br>
caseOf: {<br>
[Rabbit] -> [foo doRabbitThing].<br>
[Fox] -> [foo doFoxThing]}<br>
... which of course merely (badly) replicates class lookup/inheritance/message-sending. It suggests a writer that cannot escape the mental prison of C-like assault coding.<br>
<br>
isKindOf: is a useful meta-programming idiom that I've seen used inside inner loops to do the same sort of not-message-sending. I've even had people try to justify is on the grounds that "sending messages is so slow and I want ot avoid it", which is just nuts.<br>
<br>
isBlahClass is almost as horrible but at least has the excuse of (hopefully) being part of a not yet completed cleaning of other nastiness.<br>
<br>
Part of the problem is that language flexibility always ends up being a tool that lets annoying people write bad FORTRAN in any language. And then somebody has to spend a too large fraction of their life trying to fix it.<br>
<br>
tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" target="_blank">http://www.rowledge.org/tim</a><br>
Useful random insult:- Not enough sense to come in out of the rain.<br>
<br>
<br>
<br>
</div>
</span></span>
</div>
<br>
</blockquote></div>
</div></blockquote></div>