Re: [Pharo-dev] Rationale behind the "ifTrue:/ifFalse: returns instead of and:/or:'s" rule

April 7, 2017

      2017-04-07 11:03 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice@gmail.com>:
...
Hi Yuriy,
to me the first form is a list of simple rules.
The second one is a complex expression
You made an effort to keep the list format for the second expression,
while violating traditional block formatting which would be
^ backgroundColor isNil
or: [
                (backgroundColor isColor and: [ backgroundColor
isTranslucentButNotTransparent ]) or: [
                borderColor isColor and: [ borderColor
isTranslucentButNotTransparent ] ] ]
Sorry, premature post caused by missuse of tab key, traditional format
could be something like:

    isTranslucentButNotTransparent

        ^ backgroundColor isNil
                   or:
                       [ (backgroundColor isColor and: [ backgroundColor
isTranslucentButNotTransparent ])
                           or:
                               [ borderColor isColor and: [ borderColor
isTranslucentButNotTransparent ] ] ]

Personnally, I like this indentation better.
It's still preserving the list of simple rules, and indicate a hierarchy
among the rules
But indentations sounds overkill and won't scale very high.

To me the first form is nearer the pattern matching style of a functional
language.
...
I don't think that runtime optimization count at all in such choice.
2017-04-07 10:33 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk@me.com>:
...
Hi, there is a rule that suggests to use and/or boolean operations
instead of multiple returns.
For example it suggests agains using:
isTranslucentButNotTransparent
backgroundColor ifNil: [ ^ true ].
                (backgroundColor isColor and: [ backgroundColor
isTranslucentButNotTransparent ]) ifTrue: [ ^ true ].
                (borderColor isColor and: [ borderColor
isTranslucentButNotTransparent ]) ifTrue: [ ^ true ].
                ^ false
Instead you should use:
isTranslucentButNotTransparent
^ backgroundColor isNil or: [
                (backgroundColor isColor and: [ backgroundColor
isTranslucentButNotTransparent ]) or: [
                borderColor isColor and: [ borderColor
isTranslucentButNotTransparent ] ] ]
And at least a few developers think that the suggested implementation is
more complicated to comprehend.
What is the reasoning behind the rule? Does the suggested version run
faster (i.e. is optimized ing some way?).
Cheers.
Uko