[squeak-dev] #isNilOr:, #notNilAnd:

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sun Mar 22 19:48:06 UTC 2020

Hi all,


> 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



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.



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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200322/30f60102/attachment-0001.html>

More information about the Squeak-dev mailing list