Hi all,


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

Thank you! I'll put this onto my to-do list again (but will have a short vacation first). :-)



> If you need more than a few of these, you're circumventing the actual method dispatch by dispatching on identity manually.

Dispatching on identity is not possible always, I guess? Consider the example in PreferenceBrowserMorph I mentioned earlier (I think we have many of them in Morphic). I don't think something like an extension method Character >> #doKeyboardActionForPreferenceBrowserMorph: would be an appropriate refactoring here. ;-)
Still, I see your point that #caseOf:[otherwise:] *can* be a code smell and point to a necessary refactoring in the form of dispatching. If I would read something like "anObject class caseOf: {...", I would definitively dislike that, too, of course.
Nevertheless, I think that dispatching solutions do not scale well for small snippets in all situations. Unless I find multiple instances of such a coding smell, I would hesitate to apply a fancy pattern (Simple Design, DTSTTCPW, YAGNI, Rule of Three, etc.). In such situations, I think #caseOf:[otherwise:] is just a helper to write less duplicated code.
And LBNL, Levente's new proposal shows additional use cases for #caseOf: that go beyond simple identity dispatching. :-)

btw:

> If you're building a bytecode interpreter, fine, but in that case, metaprogramming or code generation is not too far fetched either.

Is code generation really advisable whenever you have an alternative? I don't have experience with it, but when I hear "generation" I always have to think of "synchronization issues", too ... You are building derived structures that either need to be kept in sync with the originating structure, or that have to be considered as read-only which makes tooling even harder. Or is this only my impression?

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Tobias Pape <Das.Linux at gmx.de>
Gesendet: Sonntag, 28. März 2021 16:48:22
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] #identityCaseOf:



> On 28. Mar 2021, at 16:03, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
> On Sun, 28 Mar 2021, Tobias Pape wrote:
>
>> Hi
>>
>>
>>> On 28. Mar 2021, at 07:12, tim Rowledge <tim at rowledge.org> wrote:
>>>> On 2021-03-27, at 11:47 AM, Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de> 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?
>>> I would go with 'not'. I'm not a fan of #caseOf: either. Far too like C. Slippery slope to "oooh, let's have thing.ivar.ivar to be like structs."
>>
>> Exactly.
>> If you need something like that, there's either a missing polymorphic abstraction, or a few ifTrue:'s are sufficient.
>> (as in the case of #update:
>>
>> update: aSymbol
>>
>> aSymbol == #foo ifTrue: [^ self knorz].
>> aSymbol == #bar ifTrue: [^ self berfp].
>> ^ false
>>
>> I think this is sufficient.
>
> Those ifTrue:'s quickly render your code unreadable or force you to extract chunks of your code into a separate method which can impair legibility.


If you need more than a few of these, you're circumventing the actual method dispatch
by dispatching on identity manually.
Why making such nonsense easier?

If you're building a bytecode interpreter, fine, but in that case, metaprogramming or code generation is not too far fetched either.

-t

>
>>
>> Otherwise, use an IdentityDictionary?
>
> Ah, the good old Pharo-way of doing things. :D
>
> All-in-all, it looks as though we're slipping into another caseOf: vs no-caseOf: discussion. Let's not do that.
>
>
> Levente
>
>>
>> Best regards
>>       -Tobias
>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210328/53f76bd4/attachment.html>