[squeak-dev] #identityCaseOf:

David T. Lewis lewis at mail.msen.com
Sat Mar 27 23:46:48 UTC 2021


On Sat, Mar 27, 2021 at 06:47:52PM +0000, 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?
> 

IMHO, this is not needed. It seems like cognitive clutter to me.


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

Looking at your example, I find the boring list of if checks to be easier to
read and understand.  If you were to implement it with #identityCaseOf:[otherwise:]
then I, as the reader of the code, would need to understand the distinction
between #caseOf: and #identityCaseOf:. That is not difficult, but it would
be an unnecessary distraction compared to your boring code, which I find to
be already very clear. Furthermore, your boring implementation is more
concise, and it does not require an extra clause for the otherwise: case.

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

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.

Interesting idea though :-)

Dave



More information about the Squeak-dev mailing list