Hi Christoph.

-1000 for adding #isNilOr:, #notNilAnd: and similar. :-)

Here is why:

> The names tell you when you should send which message.
> I don't see why you would not like to see #isNilOr: or #notNilAnd: in "production" code? I think their names are self-explaining.

Any kind of nil-check should be carefully questioned. Code readability is impaired for the very reason that the reader stumbles upon the term "nil", which belongs to no actual domain.

Only basic system modules should be allowed to make use of nil-checks. For any higher-level module, there are object-oriented patterns that help express "empty objects" appropriately.

We have what's already there and used. It's tricky to change that. BUT we can avoid adding more such things that would encourage sprinkling nil-checks all over the place -- even in higher-level models and production code.

> However, I think this would be a client problem rather than a design problem.

That's the thing. People will use what's there. They might not always question their decisions. They might not even refactor their programs to make the code look good. They are just happy if a program does what it should. The hassle of debugging and change might only hit other programmers later in the process. That's bad.

We should not open such a Pandora's box. ;-)

> To me, this reads rather ugly. 

Well, I do prefer "notNil and" over "notNilAnd:" just because of the extra space. I, personally, can read that more easily.

Best,
Marcel

P.S.: I think that programmers who like using cascades do also like using #in: from time to time. :-) #in: can make an intention more clear than #ifNotNil: because it avoids the nil-check.

Am 23.03.2020 02:38:38 schrieb tim Rowledge <tim at rowledge.org>:


> On 2020-03-22, at 6:29 PM, Levente Uzonyi wrote:
>
> 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.

Oh. My.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: HAL: Murder Operator



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200323/fa11f79a/attachment.html>