The idea in Smalltalk is to push a method as high as makes sense and no higher, so that if you send a message to an object where it really does not make sense (like trying to add two strings) you get a runtime failure. (Try asking an old-timer about automatic conversions in PL/I some time.) Now Lisp *did* define NIL=false, anything else=true, and Lisp came before Smalltalk, and you can bet the designers of Smalltalk knew about this possibility. As a particular example, I seem to forget to initialise variables embarrassingly often, and having x ifTrue: ... ifFalse: ... fail noisily because x was still nil has made my life simpler too often. On 20 March 2018 at 02:16, Petr Fischer <petr.fischer@me.com> wrote:
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