inquiring question about ifTrue: implementation
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
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: [ ... ]
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
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
On 19 March 2018 at 13:40, Petr Fischer <petr.fischer@me.com> wrote:
How would you define the semantics of
123 ifTrue: [ ... ]
123 is not "true", so, ignore the block.
What anout 123 ifFalse: [ ⦠], then, given that 123 is not false either?
Yes :) 123 is not false, so ignore the block again. Esteban explained it to me via "fail noisily" and "Rule of Repair" in this thread. Thanks! 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
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
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
+ 1 :) On Mon, Mar 19, 2018 at 2:16 PM, 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
participants (6)
-
Damien Pollet -
Esteban A. Maringolo -
Petr Fischer -
Richard O'Keefe -
Stephane Ducasse -
Sven Van Caekenberghe