On Aug 16, 2016, at 5:45 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
2016-08-16 23:19 GMT+02:00 John Brant <brant@refactoryworkers.com>: 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