- Pharo-users - lists.pharo.org

Re: [Pharo-users] ifNotEmpty(Do):

by Peter UhnÃ¡k

On Sun, Oct 11, 2015 at 1:11 PM, monty <monty2(a)programmer.net> 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

Oct. 11, 2015

Re: [Pharo-users] ifNotEmpty(Do):

by monty

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" <marcus.denker(a)inria.fr> > To: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Subject: Re: [Pharo-users] ifNotEmpty(Do): > > > > On 10 Oct 2015, at 18:55, Peter UhnÃ¡k <i.uhnak(a)gmail.com> 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 > > >

Oct. 11, 2015

Re: [Pharo-users] ifNotEmpty(Do):

by Marcus Denker

> On 10 Oct 2015, at 18:55, Peter UhnÃ¡k <i.uhnak(a)gmail.com> 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

Oct. 11, 2015

Re: [Pharo-users] Multiple method deletion

by Hilaire

Le 10/10/2015 20:47, stepharo a Ã©crit : > Yes I understand but with Pharo 30 and 40 I did not get this feeling. > Also introducing package and tag makes things more complex. > and I was talking about Pharo 50. Yes. I have issues from time to time with 30. > I think that we will have probably some glitches because we cleaned a > lot of code. > And we will have to do another pass. > I think that as a community we should report and help us to fix all > the tools glitches. I reported several and try to look at. It is hard to see how these situations evolves, because an application development cycle does not follow the Pharo one (for example Dr.Geo is still based to Pharo3) Hilaire -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Oct. 11, 2015

Re: [Pharo-users] Multiple method deletion

by stepharo

Yes I understand but with Pharo 30 and 40 I did not get this feeling. Also introducing package and tag makes things more complex. and I was talking about Pharo 50. I think that we will have probably some glitches because we cleaned a lot of code. And we will have to do another pass. I think that as a community we should report and help us to fix all the tools glitches. Stef Le 10/10/15 11:35, Hilaire a Ã©crit : > Le 10/10/2015 09:57, stepharo a Ã©crit : >> Are you sure? >> Because I code daily with it and I never got this behavior. >> I will try. >> Hilaire I can tell you that we worked a lot to improve it. >> >> Stef > This is how I fell it, and apparently other feel the same. > No doubt a lot of care is put into it, a reliable (or unreliable) > browser is the first things developpers notice. > > Hilaire >

Oct. 10, 2015

Re: [Pharo-users] Better Code Completion

by stepharo

But we should improve. It would be good to have someone taking that challenge because he would impact our all lives :) Le 10/10/15 12:22, Werner Kassens a Ã©crit : > On 10/10/2015 09:50 AM, stepharo wrote: >> the code should be in the image :) > > Hi Stephane, > of course. but sometimes i only discover some nice pharo code by > reading a paper. i discovered ocompletion in the image only after > having read that paper mentioned by Peter, and - thinking "yes, that > should work" - after trying out ocompletion i noticed that it is > indeed better than the default setting <g>. > werner > >

Oct. 10, 2015

Re: [Pharo-users] ifNotEmpty(Do):

by Yuriy Tymchuk

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 <i.uhnak(a)gmail.com> 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 > >

Oct. 10, 2015

Re: [Pharo-users] Multiple method deletion

by stepharo

Le 10/10/15 12:38, Peter UhnÃ¡k a Ã©crit : > I've been experiencing something similar, but I am using older Pharo > ( 50287 ) and I wasn't quite able to precisely observe the reason for > the error. There the problem was that I deleted a method, but the > previously selected method was actually deleted, so there were some > selection inconsistencies... (so I just got into the habit of > reselecting...) Thanks this is interesting to spot the problem. Stef > > P > > On Sat, Oct 10, 2015 at 11:35 AM, Hilaire <hilaire(a)drgeo.eu > <mailto:hilaire@drgeo.eu>> wrote: > > Le 10/10/2015 09:57, stepharo a Ã©crit : > > Are you sure? > > Because I code daily with it and I never got this behavior. > > I will try. > > Hilaire I can tell you that we worked a lot to improve it. > > > > Stef > > This is how I fell it, and apparently other feel the same. > No doubt a lot of care is put into it, a reliable (or unreliable) > browser is the first things developpers notice. > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > http://google.com/+DrgeoEu > > > >

Oct. 10, 2015

Re: [Pharo-users] Multiple method deletion

by stepharo

Thanks cyril I tried and I will try to reproduce it. If this happens again please try to tell us - was it when you removed one method? - was it when you removed multiple methods? Le 10/10/15 12:24, Ferlicot D. Cyril a Ã©crit : > Le 10/10/2015 07:57, stepharo a Ã©crit : >> Are you sure? >> Because I code daily with it and I never got this behavior. >> I will try. >> Hilaire I can tell you that we worked a lot to improve it. >> >> Stef >> >> > I experienced it 4-5 times this week. >

Oct. 10, 2015

Re: [Pharo-users] ifNotEmpty(Do):

by 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:pharo-users-bounces@lists.pharo.org] On Behalf Of Peter UhnÃ¡k Sent: Saturday, October 10, 2015 6:55 PM To: Pharo Users List <pharo-users(a)lists.pharo.org> 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

Oct. 10, 2015