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

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@lists.squeakfoundation.org> im Auftrag von Stéphane Rollandin <lecteur@zogotounga.net>
Gesendet: Sonntag, 22. März 2020 09:03:42
An: squeak-dev@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