[squeak-dev] #isNilOr:, #notNilAnd:
Christoph.Thiede at student.hpi.uni-potsdam.de
Sun Mar 22 19:48:06 UTC 2020
> 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...
More information about the Squeak-dev