Hi Levente,

On Sun, Mar 22, 2020 at 6:29 PM Levente Uzonyi <leves at caesar.elte.hu> wrote:

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

Ah, now I see.  Agreed.


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


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200325/23439d30/attachment.html>