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