Shouldn't ifEmpty return self?

Klaus D. Witzel klaus.witzel at cobss.com
Tue Jun 13 06:47:53 UTC 2006


On Tue, 13 Jun 2006 01:08:19 +0200, Andreas Raab <andreas.raab at gmx.de>  
wrote:
> Klaus D. Witzel wrote:
>> 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
>
> Geesh. Try to do some reading next time before you write something.

Keep cool, I just mistakenly typed #ifFalse: instead of copying your  
"False>>ifTrue:" no need to assume something about what other people  
actually *do* read, you're > 80% times wrong anyways ;-)

> I was talking about ifTrue: (not ifFalse:)

Yes, I'm sorry I made that typo. Will you ever forgive :)

> since you were questioning the *implementation* of True>>ifTrue: (which  
> is obviously correct) in the context of the ifEmpty: discussion which is  
> just as obviously determined by False>>ifTrue:. But if you're really  
> into splitting hairs, then go change "Execution does not actually reach  
> here" into "Execution does not usually reach here" which is arguably  
> more accurate.

Of course, I don't know how to split hairs :)

But let us be concerned about the quality of doc versus code, even in  
Squeak. Did you see how much time it took > 3 people for finding out  
*what* actually happens *where*. Would you expect that (bytecode view for  
finding out whether #ifTrue: is optimized away, for example as jumpFalse:)  
 from the next newcomer to Squeak?

Keep cool :) From now on we can, in case such a question comes up again,  
refer to this thread and your fine suggestions.

/Klaus

>    - Andreas




More information about the Squeak-dev mailing list