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>
> 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.
> - Andreas
More information about the Squeak-dev