> On Aug 16, 2016, at 5:45 PM, Nicolas Cellier
> <[email protected]> wrote:
>
> 2016-08-16 23:19 GMT+02:00 John Brant <[email protected]>:
> I’m guessing that it is using the read before written tester from the
> refactoring browser. It treats ifTrue:ifFalse:/ifFalse:ifTrue: blocks and the
> receiver blocks of whileTrue/False: specially. All other blocks are
> considered potentially not executed. Therefore, it says that the or: block
> may not be executed so the “element” reference in the whileFalse: argument
> block may be read without any assignment.
>
>
> Since or: and: are pretty much like ifTrue: ifFalse: they should better be
> treated as specially.
#ifTrue: and #ifFalse: blocks aren’t handled specially since we can’t guarantee
that the block is evaluated. #ifTrue:ifFalse: and #ifFalse:ifTrue: are handled
specially since we can guarantee that one of the two blocks are executed.
Therefore, if the variable is assigned before read in both blocks we can say
that it is assigned before read for the rest of the method. I never implemented
and:/or: support in the read before written tester since for the refactorings
that I performed it was never a problem, and it is more complicated to
implement. For example, you have to look at and:/or:’s in combination with
outer and:/or:/ifTrue:{ifFalse:}/ifFalse:{ifTrue:}/whileTrue{:}/whileFalse{:}
messages. Furthermore, you need to look to see if the opposite side of the
condition contains a return. For example, we could have something like this:
(condition and: [variable := otherCondition]) ifFalse: [^self].
self doSomethingWith: variable
Here “variable” is always assigned before read since “condition” had to be true
to get to the #doSomethingWith: line.
John Brant
