On Tue, 13 Jun 2006 00:13:18 +0200, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>> Ah. And I was believing the description in True>>#ifTrue:
>> -------
>> ifTrue: alternativeBlock
>>     "Answer the value of alternativeBlock. Execution does not actually
>>     reach here because the expression is compiled in-line."
>>      ^alternativeBlock value
>> -------
>>  So the bug is in the documentation? This is not an easy one: who would  
>> doubt the implementation of such an essential behavior?
>
> I don't see a bug in either the implementation nor the documentation of  
> ifTrue:/ifFalse:. You need to look at False>>ifTrue: if you want to  
> understand the described behavior of ifEmpty:

No. I do not look into the implementation of #ifFalse: for finding out if  
the implemntaion of #ifTrue: matches its own specification ;-) Nobody does  
:-D

> False>>ifTrue: alternativeBlock
> 	"Since the condition is false, answer the value of the false  
> alternative,
> 	which is nil. Execution does not actually reach here because the
> 	expression is compiled in-line."
>
> 	^nil
>
> And now it gets perfectly clear that if you want your result in ifEmpty:  
> you need to change it to something like here:
>
> Collection>>ifEmpty: aBlock
>          "Evaluate the block if I'm empty"
>
>          ^ self isEmpty ifTrue: aBlock ifFalse:[self]

+(1 big)

> (note that even if False>>ifTrue: were implemented differently it  
> couldn't possibly return anything that was involved in the computation  
> of that boolean value so regardless of whatever you're trying to do  
> [True|False]>>ifTrue: is the wrong place to achieve it - at best it  
> would result in ifEmpty: returning false instead of nil ;-)

..or what Ron was asking for: self. Then #ifEmpty: really becomes flexible

	temp := aCollection ifEmpty: [nil].

/Klaus

> Cheers,
>    - Andreas
>
>