inquiring question about ifTrue: implementation
Locked
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 |
Re: inquiring question about ifTrue: implementation
|
|
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 <[hidden email]> 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 > |
Re: inquiring question about ifTrue: implementation
|
|
> 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 <[hidden email]> 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 > > > > |
Re: inquiring question about ifTrue: implementation
|
|
On 19 March 2018 at 13:40, Petr Fischer <[hidden email]> wrote:
> How would you define the semantics of What anout 123 ifFalse: [ … ], then, given that 123 is not false either? |
Re: inquiring question about ifTrue: implementation
|
|
In reply to this post by Petr Fischer
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 <[hidden email]>: >> 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 <[hidden email]> 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 >> > >> >> > |
Re: inquiring question about ifTrue: implementation
|
|
In reply to this post by Damien Pollet-2
> On 19 March 2018 at 13:40, Petr Fischer <[hidden email]> 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 |
Re: inquiring question about ifTrue: implementation
|
|
In reply to this post by Esteban A. Maringolo
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 <[hidden email]>: > >> 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 <[hidden email]> 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 > >> > > >> > >> > > > |
Re: inquiring question about ifTrue: implementation
|
|
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 <[hidden email]> wrote: That sounds correct. In this context, my "universal ifTrue:" is really terrible idea. |
Re: inquiring question about ifTrue: implementation
|
|
In reply to this post by Petr Fischer
+ 1
:) On Mon, Mar 19, 2018 at 2:16 PM, Petr Fischer <[hidden email]> 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 <[hidden email]>: >> >> 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 <[hidden email]> 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 >> >> > >> >> >> >> >> > >> > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |