That sounds correct. In this context, my "universal ifTrue:" is really terrible idea. Thanks for clarification! pf
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.fischer@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.fischer@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