<div dir="ltr"><div dir="ltr">Hi Levente,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 22, 2020 at 6:29 PM Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu">leves@caesar.elte.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Eliot,<br>
<br>
On Sun, 22 Mar 2020, Eliot Miranda wrote:<br>
<br>
> Hi Levente,<br>
><br>
>> On Mar 22, 2020, at 1:31 PM, Levente Uzonyi <<a href="mailto:leves@caesar.elte.hu" target="_blank">leves@caesar.elte.hu</a>> wrote:<br>
>> <br>
>> Hi Christoph,<br>
>> <br>
>>> On Sun, 22 Mar 2020, Thiede, Christoph wrote:<br>
>>> <br>
>>> Hi all,<br>
>>> Levente:<br>
>>> > Both #isNilOr: and #notNilAnd: return a boolean value. It is possible to use these methods and ignore their return values. E.g.:<br>
>>> > <br>
>>> > object ifNotNil: [ collection add: object ].<br>
>>> > <br>
>>> > can be written as:<br>
>>> > <br>
>>> > object isNilOr: [ collection add: object ].<br>
>>> > <br>
>>> > or as:<br>
>>> > <br>
>>> > object notNilAnd: [ collection add: object ].<br>
>>> I see your point. However, I think this would be a client problem rather than a design problem. :-)<br>
>> <br>
>> I fully agree this is a "client problem". Have a look at the senders of #in: in a Trunk image (82 senders).<br>
>> 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.<br>
><br>
> 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.<br>
<br>
I would disagree with that too, but my problem is with the widespread <br>
misuse of #in:. #ifNotNil: is great.<br>
I suggest you have a look at #in:'s senders in your image.<br></blockquote><div><br></div><div>Ah, now I see.  Agreed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
<br>
Levente<br>
<br>
><br>
><br>
>> 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:.<br>
>> <br>
>> <br>
>> Levente<br>
>> <br>
>>> 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:<br>
>>> aBoolean ifTrue: aBlock<br>
>>> can be written as:<br>
>>> aBoolean ==> aBlock<br>
>>> The return value is significant. Otherwise, you could compare the following:<br>
>>> aCollection do: aBlock<br>
>>> aCollection collect: aBlock<br>
>>> aCollection select: aBlock<br>
>>> ...<br>
>>> Eliot:<br>
>>> 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<br>
>>> Object instead.<br>
>>> Best,<br>
>>> Christoph<br>
>>> _________________________________________________________________________________________________________________________________________________________________________________________________________________________________<br>
>>> Von: Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von Stéphane Rollandin <<a href="mailto:lecteur@zogotounga.net" target="_blank">lecteur@zogotounga.net</a>><br>
>>> Gesendet: Sonntag, 22. März 2020 09:03:42<br>
>>> An: <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
>>> Betreff: Re: [squeak-dev] #isNilOr:, #notNilAnd: <br>
>>> > The whole point of ProtoObject is to support transparent proxies that<br>
>>> > raise doesNotUnderstand: when sent any message. All the protocol in<br>
>>> > ProtoObject other than doesNotUnderstand: is a colossal mistake and the<br>
>>> > result of serious misunderstanding of the utility and implementation of<br>
>>> > transparent forwarders.<br>
>>> +1<br>
>>> Stef<br>
>><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div>