Hi all!

#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.

In my opinion, good examples for #caseOf:(otherwise:) include (but are not limited to):

PNMReadWriter >> #nextImage
CompiledCode >> #scanFor:
Character >> #isSeparator
Context >> #exceptionMessage
DoItFirst >> #keyFor:
HandMorph >> #processEvents
Inspector >> #inspectorKey:from:
ProcessBrowser >> #processListKey:from:
MimeConverter class >> #forEncoding:
WebUtils class >> #jsonDecode:

Well, not-so-good examples include (but are not limited to):

MenuMorph >> #handleFiltering:
Text >> #format:
CompiledMethod >> #scanForInstructionPattern:

There, I would opt for the good-ol' #ifTrue:ifFalse:. Or maybe an "extract method"-refactoring might improve the intend and readability of those.

Any change to #caseOf: MUST account for the Decompiler. Even the introduction of an #identityCaseOf:(otherwise:).

"true caseOf: { ... }" is an anti pattern. Please don't do that. :-)

Best,
Marcel
Am 07.04.2021 20:13:45 schrieb Jakob Reschke <jakres+squeak at gmail.com>:
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..."

Regarding letting people choose their protocols, just make sure that Smalltalk does not end up being a write-only-for-me language like Perl. :-)
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.



Am Mi., 7. Apr. 2021 um 17:53 Uhr schrieb Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]>:

Woah, I didn't know that this topic has been such a hot potato. :-)
[http://www.hpi.de/]

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).
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:.
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.

Best,
Christoph
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org]> im Auftrag von tim Rowledge <tim at rowledge.org [mailto:tim at rowledge.org]>
Gesendet: Sonntag, 28. März 2021 19:07:58
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #identityCaseOf:
 


> On 2021-03-28, at 4:09 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de [mailto:Christoph.Thiede at student.hpi.uni-potsdam.de]> wrote:
>
> @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.

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.

e.g.
foo class
        caseOf: {
                [Rabbit] -> [foo doRabbitThing].
                [Fox] -> [foo doFoxThing]}
... 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.

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.

isBlahClass is almost as horrible but at least has the excuse of (hopefully) being part of a not yet completed cleaning of other nastiness.

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.

tim
--
tim Rowledge; tim at rowledge.org [mailto:tim at rowledge.org]; http://www.rowledge.org/tim [http://www.rowledge.org/tim]
Useful random insult:- Not enough sense to come in out of the rain.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210420/79b0ecf3/attachment.html>