Re: [Pharo-users] inquiring question about ifTrue: implementation

[Stephane Ducasse]

+ 1

:)

On Mon, Mar 19, 2018 at 2:16 PM, Petr Fischer  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 :
>> >> 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  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: [Pharo-users] 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  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 :
> > >> 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  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: [Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

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 :
> >> 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  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: [Pharo-users] inquiring question about ifTrue: implementation

[Petr Fischer]

> On 19 March 2018 at 13:40, Petr Fischer  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: [Pharo-users] inquiring question about ifTrue: implementation

[Esteban A. Maringolo]

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 :
>> 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  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: [Pharo-users] inquiring question about ifTrue: implementation

[Damien Pollet]

On 19 March 2018 at 13:40, Petr Fischer  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?

Re: [Pharo-users] 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  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: [Pharo-users] inquiring question about ifTrue: implementation

[Sven Van Caekenberghe]

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

[Pharo-users] 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