Shouldn't ifEmpty return self?

Andreas Raab andreas.raab at gmx.de
Tue Jun 13 07:57:45 UTC 2006


Klaus D. Witzel wrote:
> 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 ;-)

If you meant to write "False>>ifTrue:" instead of ifFalse: your comment 
makes no sense whatsoever to me. Seriously, your first comment about not 
looking at the implementors of ifFalse: when looking into an ifTrue: 
issue is at least logical (though not what I said) but with your latter 
statement it makes no sense. Why wouldn't you look at False>>ifTrue: if 
that is the code that is actually executed by ifEmpty:?

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

If you are interested in finding out whether something gets inlined or 
not? Absolutely. It's the only sure way to find out and the sooner you 
learn about it, the better. Sure, improving the comment will help, but 
if you want to find out the truth of the situation there is no avoiding 
the bytecode view.

Cheers,
   - Andreas



More information about the Squeak-dev mailing list