Hi Eliot,

On Sun, 22 Mar 2020, Eliot Miranda wrote:

> Hi Levente,
>
>> On Mar 22, 2020, at 1:31 PM, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> 
>> Hi Christoph,
>> 
>>> On Sun, 22 Mar 2020, Thiede, Christoph wrote:
>>> 
>>> Hi all,
>>> Levente:
>>> > Both #isNilOr: and #notNilAnd: return a boolean value. It is possible to use these methods and ignore their return values. E.g.:
>>> > 
>>> > object ifNotNil: [ collection add: object ].
>>> > 
>>> > can be written as:
>>> > 
>>> > object isNilOr: [ collection add: object ].
>>> > 
>>> > or as:
>>> > 
>>> > object notNilAnd: [ collection add: object ].
>>> I see your point. However, I think this would be a client problem rather than a design problem. :-)
>> 
>> I fully agree this is a "client problem". Have a look at the senders of #in: in a Trunk image (82 senders).
>> Most uses are entirely artifical (e.g. "I just avoid declaring a temporary for no reason"), some are outrageous (e.g. I don't want to use any temporaries, and I don't want to break the cascade chain I'm in, so I use various methods accepting blocks instead of separate statements just to write my code as a single expression"), very few are legitimate.
>
> I have to say that I disagree that using ifNotNil: to avoid a temporary is outrageous :-). In fact it is part of Vassili’s design rationale for introducing ifNotNil: as an inlineable selector in the first place.  It not only localizes the declaration, changing yo to be a block argument, it makes it read-only ;a definition) and eliminates an assignment.  I’m very fond of using ifNotNil: to bind a value that is nil when it is to be ignored, and far from finding it outrageous, find it elegant.  Tastes differ.  Vice la difference.

I would disagree with that too, but my problem is with the widespread 
misuse of #in:. #ifNotNil: is great.
I suggest you have a look at #in:'s senders in your image.


Levente

>
>
>> So, yes, we have a client problem. That is why I wrote what I wrote: I expect adding these would introduce more of those misuses as with #in:.
>> 
>> 
>> Levente
>> 
>>> The names tell you when you should send which message. Each selector has a different semantic that is also formed by its return value. If we neglected the return value, we could also critique the following:
>>> aBoolean ifTrue: aBlock
>>> can be written as:
>>> aBoolean ==> aBlock
>>> The return value is significant. Otherwise, you could compare the following:
>>> aCollection do: aBlock
>>> aCollection collect: aBlock
>>> aCollection select: aBlock
>>> ...
>>> Eliot:
>>> I have to apologize, you're absolutely right on ProtoObject vs. Object. Back in December, I did not yet understand the actual idea of ProtoObject. I absolutely agree with you that any extension of this kind should go to
>>> Object instead.
>>> Best,
>>> Christoph
>>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________
>>> Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Stéphane Rollandin <lecteur at zogotounga.net>
>>> Gesendet: Sonntag, 22. März 2020 09:03:42
>>> An: squeak-dev at lists.squeakfoundation.org
>>> Betreff: Re: [squeak-dev] #isNilOr:, #notNilAnd: 
>>> > The whole point of ProtoObject is to support transparent proxies that
>>> > raise doesNotUnderstand: when sent any message. All the protocol in
>>> > ProtoObject other than doesNotUnderstand: is a colossal mistake and the
>>> > result of serious misunderstanding of the utility and implementation of
>>> > transparent forwarders.
>>> +1
>>> Stef
>>