ifNotEmpty(Do):

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

ifNotEmpty(Do):

Peter Uhnak
Collection>>ifNotEmpty: comment says

"If the block has an argument, eval with the receiver as its argument,
but it might be better to use ifNotEmptyDo: to make the code easier to
understand"

yet when I do that, Code Critic complains:
ifNotEmptyDo: should not be used as ifNotEmpty: works for blocks with arguments, too.


1) who is right? what should I use?
2) shouldn't one be deprecated then? (or maybe one of them is to be compatible with other smalltalks?)

Thanks,
Peter


Reply | Threaded
Open this post in threaded view
|

Re: ifNotEmpty(Do):

Henrik Nergaard

Look like #ifNotEmpty: is the correct choice.

 

Collection methods select: [ :m |

               (m selector          includesSubstring: 'if' caseSensitive: false) and: [

                              m selector includesSubstring: 'empty' caseSensitive: false

               ]

]

thenCollect: [ :m | m -> m senders size ]

 

"{

               Collection>>#ifEmpty:->188.

               Collection>>#ifNotEmpty:->113.

               Collection>>#ifNotEmptyDo:ifEmpty:->0.

               Collection>>#ifEmpty:ifNotEmpty:->80.

               Collection>>#ifEmpty:ifNotEmptyDo:->0.

               Collection>>#ifNotEmptyDo:->0.

               Collection>>#ifNotEmpty:ifEmpty:->14

}"

 

Best regards,

Henrik

 

From: Pharo-users [mailto:[hidden email]] On Behalf Of Peter Uhnák
Sent: Saturday, October 10, 2015 6:55 PM
To: Pharo Users List <[hidden email]>
Subject: [Pharo-users] ifNotEmpty(Do):

 

Collection>>ifNotEmpty: comment says

 

"If the block has an argument, eval with the receiver as its argument,

but it might be better to use ifNotEmptyDo: to make the code easier to

understand"

 

yet when I do that, Code Critic complains:

ifNotEmptyDo: should not be used as ifNotEmpty: works for blocks with arguments, too.

 

 

1) who is right? what should I use?

2) shouldn't one be deprecated then? (or maybe one of them is to be compatible with other smalltalks?)

 

Thanks,

Peter

 

 

Reply | Threaded
Open this post in threaded view
|

Re: ifNotEmpty(Do):

Uko2
In reply to this post by Peter Uhnak
Yes, ifNotEmptyDo: and ifNotNilDo: are for compatibility with other Smalltalks. The rule was added to communicate this in some way.

Cheers.
Uko


> On 10 Oct 2015, at 18:55, Peter Uhnák <[hidden email]> wrote:
>
> Collection>>ifNotEmpty: comment says
>
> "If the block has an argument, eval with the receiver as its argument,
> but it might be better to use ifNotEmptyDo: to make the code easier to
> understand"
>
> yet when I do that, Code Critic complains:
> ifNotEmptyDo: should not be used as ifNotEmpty: works for blocks with arguments, too.
>
>
> 1) who is right? what should I use?
> 2) shouldn't one be deprecated then? (or maybe one of them is to be compatible with other smalltalks?)
>
> Thanks,
> Peter
>
>


Reply | Threaded
Open this post in threaded view
|

Re: ifNotEmpty(Do):

Marcus Denker-4
In reply to this post by Peter Uhnak

> On 10 Oct 2015, at 18:55, Peter Uhnák <[hidden email]> wrote:
>
> Collection>>ifNotEmpty: comment says
>
> "If the block has an argument, eval with the receiver as its argument,
> but it might be better to use ifNotEmptyDo: to make the code easier to
> understand"
>

We should update the comment. I think the comment is wrong: there is nothing more
easier to understand with # ifNotEmptyDo: vs. # ifNotEmpty.

> yet when I do that, Code Critic complains:
> ifNotEmptyDo: should not be used as ifNotEmpty: works for blocks with arguments, too.
>
>
> 1) who is right? what should I use?
> 2) shouldn't one be deprecated then? (or maybe one of them is to be compatible with other smalltalk?)

We did not deprecated as this is used a lot in old code… we should move it to a compatibility package.

        Marcus


Reply | Threaded
Open this post in threaded view
|

Re: ifNotEmpty(Do):

monty-3
Not only isn't it easier to understand, it's harder. With collections "do:" normally means enumeration (do:, allButLastDo:, reverseDo:), but ifNotEmptyDo: doesn't enumerate the receiver.

> Sent: Sunday, October 11, 2015 at 5:29 AM
> From: "Marcus Denker" <[hidden email]>
> To: "Any question about pharo is welcome" <[hidden email]>
> Subject: Re: [Pharo-users] ifNotEmpty(Do):
>
>
> > On 10 Oct 2015, at 18:55, Peter Uhnák <[hidden email]> wrote:
> >
> > Collection>>ifNotEmpty: comment says
> >
> > "If the block has an argument, eval with the receiver as its argument,
> > but it might be better to use ifNotEmptyDo: to make the code easier to
> > understand"
> >
>
> We should update the comment. I think the comment is wrong: there is nothing more
> easier to understand with # ifNotEmptyDo: vs. # ifNotEmpty.
>
> > yet when I do that, Code Critic complains:
> > ifNotEmptyDo: should not be used as ifNotEmpty: works for blocks with arguments, too.
> >
> >
> > 1) who is right? what should I use?
> > 2) shouldn't one be deprecated then? (or maybe one of them is to be compatible with other smalltalk?)
>
> We did not deprecated as this is used a lot in old code… we should move it to a compatibility package.
>
> Marcus
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: ifNotEmpty(Do):

Peter Uhnak


On Sun, Oct 11, 2015 at 1:11 PM, monty <[hidden email]> wrote:
Not only isn't it easier to understand, it's harder. With collections "do:" normally means enumeration (do:, allButLastDo:, reverseDo:), but ifNotEmptyDo: doesn't enumerate the receiver.

But in Morphic/Spec/Bloc #widgetDo: is used very commonly (for DOing things, not enumerating), so it depends on the context.

I think the important lesson here is that you eventually learn patterns, so once you know what this does it's no longer less or more readable because it became habituated.

P