Why would you do such aberration? It goes against the "fail noisily" "Rule of Repair": Developers should design programs that fail in a manner that is easy to localize and diagnose or in other words “fail noisily”. This rule aims to prevent incorrect output from a program from becoming an input and corrupting the output of other code undetected.
It is semantically incorrect, if needed, I don't see why, you sould implement it in your own class. But when I needed to do such "if" handlers, I did it using meaningful selectors like #ifGranted: or #ifSucceeded:, or the well known #ifEmpty: Regards, Esteban A. Maringolo 2018-03-19 9:40 GMT-03:00 Petr Fischer <petr.fisc...@me.com>: >> Infinite recursion ? >> >> You use #ifTrue: in your implementation of Object>>#ifTrue: >> >> Plus, non-booleans cannot meaningfully respond. >> >> How would you define the semantics of >> >> 123 ifTrue: [ ... ] > > 123 is not "true", so, ignore the block. > Do the ifTrue block only if the receiver is instance of True (true). > Everything else is not "true" :) > > I missed the recursion, yes, but it could be done another way. > >> >> > On 19 Mar 2018, at 10:18, Petr Fischer <petr.fisc...@me.com> wrote: >> > >> > Hello, I have some sort of philosophical question about ifTrue:/ifFalse: >> > implementation. >> > >> > Now, ifTrue: is defined in the Boolean class (subclassResponsibility) + in >> > True and False classes, so, we can send this message to the boolean >> > expressions (instances) only, otherwise DND occurs. >> > >> > But we can also define one universal ifTrue: right in the Object class, in >> > this style: >> > >> > Object>>ifTrue: .... >> > (self = true) ifTrue: [ ... ]. >> > >> > then, we can send ifTrue: message to ANY object and it will work correctly >> > without DND exception on non-boolean objects. >> > >> > Is something bad about this idea? >> > >> > Thanks! pf >> > >> >> >
