Smalltalk › Squeak › Squeak - Dev

did ifEmpty:ifNotEmpty: change?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Chris Muller-4

did ifEmpty:ifNotEmpty: change?

I know the semantics of ifEmpty: and ifNotEmpty: changed in the trunk
image last year, to answer the receiver instead of nil in the other
case.

However, I also noticed ifEmpty:ifNotEmpty: changed but I'm not seeing
any semantic difference. Is there some subtlety I'm missing by the
new:

ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
"Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
" If the notEmptyBlock has an argument, eval with the receiver as its argument"

self isEmpty ifTrue: [ ^emptyBlock value ].
^notEmptyBlock valueWithPossibleArgument: self

vs. old:

ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
"Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
" If the notEmptyBlock has an argument, eval with the receiver as its argument"

^ self isEmpty ifTrue: emptyBlock ifFalse: [notEmptyBlock
valueWithPossibleArgument: self]

?

Thanks,
Chris

Nicolas Cellier

Re: did ifEmpty:ifNotEmpty: change?

2010/3/12 Chris Muller <[hidden email]>:

> I know the semantics of ifEmpty: and ifNotEmpty: changed in the trunk
> image last year, to answer the receiver instead of nil in the other
> case.
>
> However, I also noticed ifEmpty:ifNotEmpty: changed but I'm not seeing
> any semantic difference. Is there some subtlety I'm missing by the
> new:
>
> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>
> self isEmpty ifTrue: [ ^emptyBlock value ].
> ^notEmptyBlock valueWithPossibleArgument: self
>
> vs. old:
>
> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>
> ^ self isEmpty ifTrue: emptyBlock ifFalse: [notEmptyBlock
> valueWithPossibleArgument: self]
>
> ?
>
> Thanks,
> Chris
>

Well, just take a look to bytecodes generated by each variant.
Only an optimization I think.

Nicolas

Levente Uzonyi-2

Re: did ifEmpty:ifNotEmpty: change?

In reply to this post by Chris Muller-4

On Fri, 12 Mar 2010, Chris Muller wrote:

This version is faster than the old one, because ifTrue: is inlined.

Levente

>
> vs. old:
>
> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>
> ^ self isEmpty ifTrue: emptyBlock ifFalse: [notEmptyBlock
> valueWithPossibleArgument: self]
>
> ?
>
> Thanks,
> Chris
>
>

Chris Muller-3

Re: did ifEmpty:ifNotEmpty: change?

In reply to this post by Nicolas Cellier

I really like the new printing of CompiledMethods and the detail of
the byteCodes compared to 3.9. Certainly a big step in helping me
understand them. Now I'm going to have to review all of my code,
because I think I have not been paying attention to this sort of
optimization.

This would probably make a good Lint check..

On Fri, Mar 12, 2010 at 3:09 PM, Nicolas Cellier
<[hidden email]> wrote:

> 2010/3/12 Chris Muller <[hidden email]>:
>> I know the semantics of ifEmpty: and ifNotEmpty: changed in the trunk
>> image last year, to answer the receiver instead of nil in the other
>> case.
>>
>> However, I also noticed ifEmpty:ifNotEmpty: changed but I'm not seeing
>> any semantic difference. Is there some subtlety I'm missing by the
>> new:
>>
>> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
>> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
>> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>>
>> self isEmpty ifTrue: [ ^emptyBlock value ].
>> ^notEmptyBlock valueWithPossibleArgument: self
>>
>> vs. old:
>>
>> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
>> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
>> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>>
>> ^ self isEmpty ifTrue: emptyBlock ifFalse: [notEmptyBlock
>> valueWithPossibleArgument: self]
>>
>> ?
>>
>> Thanks,
>> Chris
>>
>
> Well, just take a look to bytecodes generated by each variant.
> Only an optimization I think.
>
> Nicolas
>
>

Levente Uzonyi-2

Re: did ifEmpty:ifNotEmpty: change?

On Fri, 12 Mar 2010, Chris Muller wrote:

> I really like the new printing of CompiledMethods and the detail of
> the byteCodes compared to 3.9. Certainly a big step in helping me
> understand them. Now I'm going to have to review all of my code,
> because I think I have not been paying attention to this sort of
> optimization.
>
> This would probably make a good Lint check..

I'm pretty sure there's a check in Lint for this.

Levente

>
> On Fri, Mar 12, 2010 at 3:09 PM, Nicolas Cellier
> <[hidden email]> wrote:
>> 2010/3/12 Chris Muller <[hidden email]>:
>>> I know the semantics of ifEmpty: and ifNotEmpty: changed in the trunk
>>> image last year, to answer the receiver instead of nil in the other
>>> case.
>>>
>>> However, I also noticed ifEmpty:ifNotEmpty: changed but I'm not seeing
>>> any semantic difference. Is there some subtlety I'm missing by the
>>> new:
>>>
>>> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
>>> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
>>> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>>>
>>> self isEmpty ifTrue: [ ^emptyBlock value ].
>>> ^notEmptyBlock valueWithPossibleArgument: self
>>>
>>> vs. old:
>>>
>>> ifEmpty: emptyBlock ifNotEmpty: notEmptyBlock
>>> "Evaluate emptyBlock if I'm empty, notEmptyBlock otherwise"
>>> " If the notEmptyBlock has an argument, eval with the receiver as its argument"
>>>
>>> ^ self isEmpty ifTrue: emptyBlock ifFalse: [notEmptyBlock
>>> valueWithPossibleArgument: self]
>>>
>>> ?
>>>
>>> Thanks,
>>> Chris
>>>
>>
>> Well, just take a look to bytecodes generated by each variant.
>> Only an optimization I think.
>>
>> Nicolas
>>
>>
>
>