Smalltalk › Squeak › Squeak - Dev

Shouldn't ifEmpty return self?

_‹ Previous Topic Next Topic _›

Classic

List

21 messages Options

Options

12

Shouldn't ifEmpty return self?

Shouldn’t ifEmpty: return self?

#(1) ifEmpty: [nil] -> Returns nil

#(1) ifNil: [nil]. -> Returns #(1)

Ron Teitelbaum

Philippe Marschall

Re: Shouldn't ifEmpty return self?

2006/6/12, Ron Teitelbaum <[hidden email]>:

>
>
>
>
> Shouldn't ifEmpty: return self?
>
>
>
> #(1) ifEmpty: [nil] -> Returns nil
>
> #(1) ifNil: [nil]. -> Returns #(1)
>
>
>
> Ron Teitelbaum

false ifTrue: [ true ] -> nil
So returning nil for #ifEmpty: is quite consitent in my eyes.

Philippe

Re: Shouldn't ifEmpty return self?

In reply to this post by Ron Teitelbaum

It would probably be more consistent with ifTrue: and ifFalse: for
ifNil: to return nil.

false ifTrue: [ 'non-nil' ] -> nil

Chris

--- Ron Teitelbaum <[hidden email]> wrote:

> Shouldn't ifEmpty: return self?
>
>
>
> #(1) ifEmpty: [nil] -> Returns nil
>
> #(1) ifNil: [nil]. -> Returns #(1)
>
>
>
> Ron Teitelbaum
>
>
>
> >
>

Re: Shouldn't ifEmpty return self?

In reply to this post by Ron Teitelbaum

Ron

in your example ( with doit)

#(1) ifEmpty: [nil]

ifEmpty block don't qualify, so return the receiver.
the receiver of Doit is UndefinedObject
from there you have nil how result
best regards
MDC
--- Ron Teitelbaum <[hidden email]> escribió:

> Shouldn't ifEmpty: return self?
>
>
>
> #(1) ifEmpty: [nil] -> Returns nil
>
> #(1) ifNil: [nil]. -> Returns #(1)
>
>
>
> Ron Teitelbaum
>
>
>
> >
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Re: Shouldn't ifEmpty return self?

In reply to this post by Ron Teitelbaum

Ron

in your example ( with doit)

#(1) ifEmpty: [nil]

ifEmpty block don't qualify, so return the receiver.
the receiver of Doit is UndefinedObject
from there you have nil how result
best regards
MDC
--- Ron Teitelbaum <[hidden email]> escribió:

> Shouldn't ifEmpty: return self?
>
>
>
> #(1) ifEmpty: [nil] -> Returns nil
>
> #(1) ifNil: [nil]. -> Returns #(1)
>
>
>
> Ron Teitelbaum
>
>
>
> >
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Joshua Gargus-2

Re: Shouldn't ifEmpty return self?

In reply to this post by Chris Muller

On Mon, 12 Jun 2006 10:29:50 -0700 (PDT), "Chris Muller"
<[hidden email]> said:
> It would probably be more consistent with ifTrue: and ifFalse: for
> ifNil: to return nil.
>
> false ifTrue: [ 'non-nil' ] -> nil
>

Perhaps more consistent, but I think less useful. You couldn't write
code like:

self doSomethingWithNonNilObject: (anObject ifNil: [self
generateNonNilObject])

Josh

> Chris
>
> --- Ron Teitelbaum <[hidden email]> wrote:
>
> > Shouldn't ifEmpty: return self?
> >
> >
> >
> > #(1) ifEmpty: [nil] -> Returns nil
> >
> > #(1) ifNil: [nil]. -> Returns #(1)
> >
> >
> >
> > Ron Teitelbaum
> >
> >
> >
> > >
> >
>
>

Boris Popov, DeepCove Labs (SNN)

RE: Shouldn't ifEmpty return self?

In reply to this post by Ron Teitelbaum

Umm, no, receiver of a doit should have nothing to do with the code being
executed. Here's a VisualWorks implementation, which is more correct given
the intent of these methods,

#(1) ifEmpty: [nil] #(1)
#() ifNotEmpty: [nil] #()

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of marcelo
Cortez
Sent: Monday, June 12, 2006 11:49 AM
To: [hidden email]; The general-purpose Squeak developers list
Subject: Re: Shouldn't ifEmpty return self?

Ron

in your example ( with doit)

#(1) ifEmpty: [nil]

ifEmpty block don't qualify, so return the receiver.
the receiver of Doit is UndefinedObject
from there you have nil how result
best regards
MDC
--- Ron Teitelbaum <[hidden email]> escribió:

> Shouldn't ifEmpty: return self?
>
>
>
> #(1) ifEmpty: [nil] -> Returns nil
>
> #(1) ifNil: [nil]. -> Returns #(1)
>
>
>
> Ron Teitelbaum
>
>
>
> >
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

smime.p7s (4K) Download Attachment

RE: Shouldn't ifEmpty return self?

Boris

you are right, i'm confused with doit method
implemented on the fly into UndefindedObject.

but False>>ifTrue: aBlock response nil.

False>>ifTrue:aBlock

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

Best regards
MDC

--- Boris Popov <[hidden email]> escribió:

> Umm, no, receiver of a doit should have nothing to
> do with the code being
> executed. Here's a VisualWorks implementation, which
> is more correct given
> the intent of these methods,
>
> #(1) ifEmpty: [nil] #(1)
> #() ifNotEmpty: [nil] #()
>
> Cheers!
>
> -Boris
>
> --
> +1.604.689.0322
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
>
> [hidden email]
>
> CONFIDENTIALITY NOTICE
>
> This email is intended only for the persons named in
> the message
> header. Unless otherwise indicated, it contains
> information that is
> private and confidential. If you have received it in
> error, please
> notify the sender and delete the entire message
> including any
> attachments.
>
> Thank you.
>
> -----Original Message-----
> From: [hidden email]
>

[mailto:[hidden email]]

> On Behalf Of marcelo
> Cortez
> Sent: Monday, June 12, 2006 11:49 AM
> To: [hidden email]; The general-purpose Squeak
> developers list
> Subject: Re: Shouldn't ifEmpty return self?
>
> Ron
>
> in your example ( with doit)
>
> #(1) ifEmpty: [nil]
>
> ifEmpty block don't qualify, so return the
> receiver.
> the receiver of Doit is UndefinedObject
> from there you have nil how result
> best regards
> MDC
> --- Ron Teitelbaum <[hidden email]> escribió:
>
> > Shouldn't ifEmpty: return self?
> >
> >
> >
> > #(1) ifEmpty: [nil] -> Returns nil
> >
> > #(1) ifNil: [nil]. -> Returns #(1)
> >
> >
> >
> > Ron Teitelbaum
> >
> >
> >
> > >
> >
>
>
> __________________________________________________
> Correo Yahoo!
> Espacio para todos tus mensajes, antivirus y
> antispam ¡gratis!
> ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
>
> >
>

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

In reply to this post by Boris Popov, DeepCove Labs (SNN)

On Mon, 12 Jun 2006 20:55:21 +0200, Boris Popov wrote:

> Umm, no, receiver of a doit should have nothing to do with the code being
> executed. Here's a VisualWorks implementation, which is more correct
> given
> the intent of these methods,
>
> #(1) ifEmpty: [nil] #(1)

That is what I expect, too.

Besides, the current Squeak implementaton of #ifEmpty: does not send
#value to its argument (a block) ... this method is perhaps an example of
one bug not canceling the other one ;-)

/Klaus

> #() ifNotEmpty: [nil] #()
>
> Cheers!
>
> -Boris
>

Benjamin Schroeder-2

Re: Shouldn't ifEmpty return self?

On Jun 12, 2006, at 3:33 PM, Klaus D. Witzel wrote:

> Besides, the current Squeak implementaton of #ifEmpty: does not
> send #value to its argument (a block) ... this method is perhaps an
> example of one bug not canceling the other one ;-)

The block ends up having #value sent to it by #ifTrue: (when
appropriate). #ifEmpty: just passes it along.

"Evaluate the block if I'm empty"

^ self isEmpty ifTrue: aBlock

Benjamin Schroeder

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

On Mon, 12 Jun 2006 22:15:51 +0200, Benjamin Schroeder wrote:

> On Jun 12, 2006, at 3:33 PM, Klaus D. Witzel wrote:
>> Besides, the current Squeak implementaton of #ifEmpty: does not send
>> #value to its argument (a block) ... this method is perhaps an example
>> of one bug not canceling the other one ;-)
>
> The block ends up having #value sent to it by #ifTrue: (when
> appropriate). #ifEmpty: just passes it along.
>
> "Evaluate the block if I'm empty"
>
> ^ self isEmpty ifTrue: aBlock
>

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?

/Klaus

Benjamin Schroeder-2

Re: Shouldn't ifEmpty return self?

On Jun 12, 2006, at 5:38 PM, 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 think I see what you're saying. I did a little digging ...

Most of the time, it's only "as if" #ifTrue:, and hence #value, gets
sent. Interestingly, the whole block gets compiled inline in these
cases:

foo

4 > 3 ifTrue: [self halt]

compiles to

17 <21> pushConstant: 4
18 <22> pushConstant: 3
19 <B3> send: >
20 <9A> jumpFalse: 24
21 <70> self
22 <D0> send: halt
23 <87> pop
24 <78> returnSelf

(This output is from the "bytecodes" choice on the source dropdown of
the browser.)

However, #ifTrue: is actually sent if the situation isn't as obvious,
as when the block is referred to using a variable:

foo

| block |
block _ [self halt].

4 > 3 ifTrue: block

compiles to

21 <89> pushThisContext:
22 <75> pushConstant: 0
23 <C8> send: blockCopy:
24 <A4 03> jumpTo: 29
26 <70> self
27 <D0> send: halt
28 <7D> blockReturn
29 <68> popIntoTemp: 0
30 <22> pushConstant: 4
31 <23> pushConstant: 3
32 <B3> send: >
33 <10> pushTemp: 0
34 <E1> send: ifTrue:
35 <87> pop
36 <78> returnSelf

I don't know if the VM recognizes sends of #ifTrue: and does any
runtime optimization on them or not.

The behavior should be the same in either case, at any rate - it
should act as though #value were sent - so I might be missing what
you're saying about a bug.

Benjamin Schroeder

Re: Shouldn't ifEmpty return self?

In reply to this post by Klaus D. Witzel

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:

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

(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 ;-)

Cheers,
- Andreas

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

In reply to this post by Benjamin Schroeder-2

On Mon, 12 Jun 2006 23:59:40 +0200, Benjamin Schroeder wrote:

> so I might be missing what you're saying about a bug.

The doc in #ifTrue: says "Execution does not actually reach here because
the expression is compiled in-line." which is not the case. So the doc is
buggy, that's what I meant earlier.

Of course I looked at the bytecode view of #ifEmpty: and also what is
contributed by #ifTrue:, which has the above comment.

/Klaus

> Benjamin Schroeder

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

In reply to this post by Andreas.Raab

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

Re: Shouldn't ifEmpty return self?

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. I
was talking about ifTrue: (not ifFalse:) 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.

- Andreas

RE: Shouldn't ifEmpty return self?

In reply to this post by Chris Muller

Hey Chris,

I expect nil on ifTrue: or ifFalse: , I'm used to self on ifEmpty: because
that's what VW does (thanks Boris!).

I've always thought of ifNil: and ifEmpty: as the same kind of exception
handler

aPerson ifNil: [twoPeople makeBaby]

aGasTank ifEmpty: [aGasTank fillerUp. aGasTank]

Or whatever - they are inline exceptions. I was merging some byteArrays
when I realized that if there were none that I would end up on a collection
instead of an empty byteArray so I tacked on an ifEmpty: [ByteArray new] and
was surprised by the nil when I wasn't empty.

And as long as we are on the subject I have more:

What's with indexOf:startingAt: ?

There's an indexOfSubcollection:startingAt: I have to tack on an ifAbsent:
block to get it to work. Seems like we should have and indexOf:startingAt:

And how come there is no explode method? I have subStrings: aDelimiter for
string but nothing for collections? I wrote one for collections called
explode: anObject but it sure seems like it should have been there
somewhere. I suggested methods before just to have someone point out the
one I missed, is there an explode like method or something that chops up
collections by some delimiter for collections?

(I'm still cutting my teeth on the differences between VW and Squeak)

Thanks!
Ron

> From: Chris Muller
> Sent: Monday, June 12, 2006 1:30 PM
>
> It would probably be more consistent with ifTrue: and ifFalse: for
> ifNil: to return nil.
>
> false ifTrue: [ 'non-nil' ] -> nil
>
> Chris
>
> --- Ron Teitelbaum <[hidden email]> wrote:
>
> > Shouldn't ifEmpty: return self?
> >
> > #(1) ifEmpty: [nil] -> Returns nil
> >
> > #(1) ifNil: [nil]. -> Returns #(1)
> >
> > Ron Teitelbaum

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

In reply to this post by Andreas.Raab

On Tue, 13 Jun 2006 01:08:19 +0200, Andreas Raab <[hidden email]>
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

Re: Shouldn't ifEmpty return self?

Klaus D. Witzel wrote:

> On Tue, 13 Jun 2006 01:08:19 +0200, Andreas Raab <[hidden email]>
> 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

Klaus D. Witzel

Re: Shouldn't ifEmpty return self?

On Tue, 13 Jun 2006 09:57:45 +0200, Andreas Raab wrote:

> Klaus D. Witzel wrote:
>> On Tue, 13 Jun 2006 01:08:19 +0200, Andreas Raab 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:?

I'm sorry that my comment made no sense for you. When I wrote it, I was
looking into the particulars of what/who eventually sends #value to aBlock
in #ifEmpty: aBlock

^ self isEmpty ifTrue: aBlock

which intuitively cannot be False>>#ifTrue: (contrasting that to: who/what
is NOT sending #value). Of course an exact examination of all implementors
of #ifTrue: would be needed if #value would have been sent in the wrong
case.

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

I could not agree less ;-) However, a problem that remains to be solved
is, how can users of the Squeak dev environment be made aware of possible
inlining. Perhaps by an appropriate comment <grin />

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

Absolutely.

/Klaus

> Cheers,
> - Andreas
>
>

12