inquiring question about ifTrue: implementation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

inquiring question about ifTrue: implementation

Petr Fischer
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

Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Sven Van Caekenberghe-2
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
>


Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Petr Fischer
> 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
> >
>
>

Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

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? 

Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Esteban A. Maringolo
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
>> >
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Petr Fischer
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


Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Petr Fischer
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
> >> >
> >>
> >>
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Richard O'Keefe
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.

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
> >> >
> >>
> >>
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: inquiring question about ifTrue: implementation

Stephane Ducasse-3
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
>> >> >
>> >>
>> >>
>> >
>>
>