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.fisc...@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.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 > > >> > > > >> > > >> > > > > > > >
