- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] flatCollect:

by Tudor Girba

Indeed, it would be great to have a polymorphic message for constructing collections. In the meantime, there are three flatCollect: methods: Collection>>flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" | stream | self isEmpty ifTrue: [ ^ self copy ]. stream := (self species new: 0) writeStream. self do: [ :each | stream nextPutAll: (aBlock value: each) ]. ^ stream contents Set>>flatCollect: aBlock ^self flatCollectAsSet: aBlock SortedCollection>>flatCollect: aBlock ^ self flatCollect: aBlock as: OrderedCollection Doru On Mon, Nov 4, 2013 at 6:02 PM, Chris Cunningham <cunningham.cb(a)gmail.com>wrote: > Right. I hadn't looked closely enough at the Moose one. Actually, if you > dig it a bit deeper, #writeStream isn't defined in the Collection hierarchy > until you get to SequenceableCollection in any case, so the Moose version > is defined too high. > > So, if there is a desire for #flatCollect: outside of > SequenceableColleciton, then this should work (based on Moose version): > > Collection>>flatCollect: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock > returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > "original written by a. Kuhn and released under MIT" > | result | > self isEmpty ifTrue: [ ^ self copy ]. > result := (self species new: 0). > self do: [ :each | result addAll: (aBlock value: each) ]. > ^ result > > > SequenceableCollection>>flatCollect: aBlock > "Evaluate aBlock for each of the receiver's elements and answer the > list of all resulting values flatten one level. Assumes that aBlock > returns some kind > of collection for each element. Equivalent to the lisp's mapcan" > "original written by a. Kuhn and released under MIT" > | stream | > self isEmpty ifTrue: [ ^ self copy ]. > ^self species streamContents: [ :stream | > self do: [ :each | stream nextPutAll: (aBlock value: each) ] > > > -Chris > On Mon, Nov 4, 2013 at 8:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> Actually I am still confused about this, for example, >> >> Set new writeStream nextPut: 1; contents >> >> does not work, so for which non-sequenceable collections would the >> #flatCollect: code work ? >> >> I was thinking that maybe #streamContents: could be put higher up ? >> If that would not be possible, why not ? >> And how would the #flatCollect: code then work ? >> >> On 04 Nov 2013, at 17:36, Chris Cunningham <cunningham.cb(a)gmail.com> >> wrote: >> >> > On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> >> wrote: >> > Indeed, it would be more elegant, but streamContents: is only defined >> in SequeanceableCollection, so it is not generic enough. >> > >> > So, then use the generic one where it is defined (Collection), and a >> more specific one that Sven suggested in SequenceableCollection. >> > >> > -Chris >> > >> > Doru >> > >> > >> > On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too >> might needs the #species >> > >> > Would it also not be better and more elegant to say >> > >> > self species streamContents: [ :stream | >> > â¦ ] >> > >> > ? >> > >> > On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> > >> > > >> > > On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > > >> > >> Hi, >> > >> >> > >> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great >> as the method proved to be very valuable in the context of Moose. >> > >> >> > >> However, the current Pharo implementation is less ideal: >> > >> >> > >> Collection>>flatCollect: aBlock >> > >> ^ Array streamContents: >> > >> [:stream | >> > >> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] >> > >> >> > >> The Moose one is: >> > >> Collection>>flatCollect: aBlock >> > >> "Evaluate aBlock for each of the receiver's elements and answer >> the >> > >> list of all resulting values flatten one level. Assumes that >> aBlock returns some kind >> > >> of collection for each element. Equivalent to the lisp's mapcan" >> > >> "original written by a. Kuhn and released under MIT" >> > >> >> > >> | stream | >> > >> self isEmpty ifTrue: [ ^ self copy ]. >> > >> stream := (self species new: 0) writeStream. >> > >> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. >> > >> ^ stream contents >> > >> >> > >> The difference is in the type returned. The Pharo one always returns >> Array, while the Moose one returns a collection of the same species as the >> receiver. >> > > >> > > Sounds right, returning #species. >> > > >> > >> Does anyone have anything against the Moose implementation? >> > >> >> > >> Doru >> > >> >> > >> -- >> > >> www.tudorgirba.com >> > >> >> > >> "Every thing has its own flow" >> > >> > >> > >> > >> > >> > -- >> > www.tudorgirba.com >> > >> > "Every thing has its own flow" >> > >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by Alexandre Bergel

+1 Everybody is waiting for using Git with Pharo. There is a real possibility to impact 100s of users... Go go go! Alexandre Alexandre > Le 04-11-2013 Ã 15:35, kilon alios <kilon.alios(a)gmail.com> a Ã©crit : > > Yeah I agree, this is an awesome project and thank you for your hard work :) > > >> On Mon, Nov 4, 2013 at 8:12 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: >> Hi Max, >> >> I saw you were on it :) It's a huge effort you're undertaking. I learned a bit about git internal storage stepping through the code. >> >> Thierry >> >> ________________________________________ >> De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Max Leske [maxleske(a)gmail.com] >> Date d'envoi : lundi 4 novembre 2013 17:44 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Github and Pharo >> >> FileSystem-Git is basically in alpha at the momentâ¦ Iâm rewriting it. >> >> >> On 04.11.2013, at 17:04, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> > Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... >> > >> > I tried on one of my work repository, and: >> > - it failed trying to uft8convert a packed data file. >> > So I corrected the error (get the stream as binary!) and >> > - It failed looking for one of the commit IDs >> > I found the ref in a pack file; apparently, it's not looking in there... >> > I'm forcing a read of the pack files in there >> > - Yet another utf8convert error on binary data >> > Corrected, I got the pack files, but the index isn't telling me much. >> > I tried to list the objects in it... Unknown compression method error. >> > >> > There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) >> > >> > Thierry >> > >> > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : >> >> >> >> >> >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : >> >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: >> >>>> >> >>>> >> >>>> Le 04/11/2013 12:11, kilon alios a ?crit : >> >>>>> yeap filetree did the trick here. However it does not allow to browse >> >>>>> through the git commits as gitfiletree does, the only commit available >> >>>>> is the last commit. >> >>>>> >> >>>>> I took a look at CommandShell and friends and they all look pretty much >> >>>>> very broken. For example in workspace I executed >> >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates an >> >>>>> error because it add C path inside pharo subdirectories. Dont know if >> >>>>> this is normal behavior. >> >>> >> >>> Use "CommandShell open" rather than "CommandShellTranscript open". >> >>> >> >>> >> >>>> >> >>>> I hope someone with more knowledge than me of OSProcess under windows >> >>>> will have a look :) >> >>>> >> >>> OSProcess support for Windows is incomplete, so this will probably not >> >>> do what you need. If the OSProcess is included in the Windows VM, it will >> >>> let you run a Windows program, but it will not do most of the other >> >>> things >> >>> that you expect from OSProcess. >> >>> >> >>> Check http://www.squeaksource.com/ProcessWrapper.html for a possible >> >>> alternative. >> >> >> >> Thanks Dave; no easy solution on that, it seems. I'll have a look then >> >> with FileSystem-Git, this one may be a more portable solution. >> >> >> >> Windows is still a world apart from the rest :( >> >> >> >> Thierry >> > >> > -- >> > Thierry Goubier >> > CEA list >> > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> > 91191 Gif sur Yvette Cedex >> > France >> > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > >

Nov. 4, 2013

Re: [Pharo-dev] Spaceship?

by Yuriy Tymchuk

No one prohibits you from redefining other operators. Itâs just that a > b is defined by default as b < a. So why it is this way and not a < b is b > a ;) With spaceship there is one method to rule them all. But Pharoâs implementation is interesting too. I never had an idea that you can define things like that On 04 Nov 2013, at 18:54, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Beware of cases where you don't have total order. > For example, in recent Squeak/Pharo we add to redefine the whole set of operators on numbers, not only < and =, just because NaN is not ordered... > > > 2013/11/4 kilon alios <kilon.alios(a)gmail.com> > It looks to me that this would be the source of less readable code, I prefer the choosing message approach by Kent Beck (Smalltalk Best Practice Patterns) where intent is clearly stated. Unless there is an advantage I am missing here. This is an example that less verbose code does not mean simpler code. Of course this will largely depend on the specifics of the case used. > > > On Mon, Nov 4, 2013 at 3:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Now she someone wantâs to have a comparable object he has to use TComparable and define < and =. > With spaceship he has to define only <=>. Iâm not sure whatâs better. Just wanted to hear other peoples opinion > > On 04 Nov 2013, at 13:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > do you have a real use case? > > > > Stef > > > > On Nov 4, 2013, at 1:32 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > >> Hi everyone. > >> > >> Iâm wandering if there was any sort of a discussion about a spaceship method used in Ruby. > >> > >> The concept is that you should implement a method <=> > >> that returns something negative if the receiver is smaller then a parameter, > >> positive when the receiver is greater then a parameter, > >> and 0 if they are equal. > >> > >> This way if you are implementing comparable objectâs the only method you have to redefine is spaceship (<=>). > >> > >> Yes, I know that i Pharo you have to only redefine < and =. But maybe it would be interesting to use spaceship :) > >> > >> What do you think? > >> Cheers! > >> Uko > > > > > > > >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by Max Leske

Thanks guys :) On 04.11.2013, at 19:35, kilon alios <kilon.alios(a)gmail.com> wrote: > Yeah I agree, this is an awesome project and thank you for your hard work :) > > > On Mon, Nov 4, 2013 at 8:12 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > Hi Max, > > I saw you were on it :) It's a huge effort you're undertaking. I learned a bit about git internal storage stepping through the code. > > Thierry > > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Max Leske [maxleske(a)gmail.com] > Date d'envoi : lundi 4 novembre 2013 17:44 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Github and Pharo > > FileSystem-Git is basically in alpha at the momentâ¦ Iâm rewriting it. > > > On 04.11.2013, at 17:04, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... > > > > I tried on one of my work repository, and: > > - it failed trying to uft8convert a packed data file. > > So I corrected the error (get the stream as binary!) and > > - It failed looking for one of the commit IDs > > I found the ref in a pack file; apparently, it's not looking in there... > > I'm forcing a read of the pack files in there > > - Yet another utf8convert error on binary data > > Corrected, I got the pack files, but the index isn't telling me much. > > I tried to list the objects in it... Unknown compression method error. > > > > There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) > > > > Thierry > > > > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : > >> > >> > >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : > >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: > >>>> > >>>> > >>>> Le 04/11/2013 12:11, kilon alios a ?crit : > >>>>> yeap filetree did the trick here. However it does not allow to browse > >>>>> through the git commits as gitfiletree does, the only commit available > >>>>> is the last commit. > >>>>> > >>>>> I took a look at CommandShell and friends and they all look pretty much > >>>>> very broken. For example in workspace I executed > >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates an > >>>>> error because it add C path inside pharo subdirectories. Dont know if > >>>>> this is normal behavior. > >>> > >>> Use "CommandShell open" rather than "CommandShellTranscript open". > >>> > >>> > >>>> > >>>> I hope someone with more knowledge than me of OSProcess under windows > >>>> will have a look :) > >>>> > >>> OSProcess support for Windows is incomplete, so this will probably not > >>> do what you need. If the OSProcess is included in the Windows VM, it will > >>> let you run a Windows program, but it will not do most of the other > >>> things > >>> that you expect from OSProcess. > >>> > >>> Check http://www.squeaksource.com/ProcessWrapper.html for a possible > >>> alternative. > >> > >> Thanks Dave; no easy solution on that, it seems. I'll have a look then > >> with FileSystem-Git, this one may be a more portable solution. > >> > >> Windows is still a world apart from the rest :( > >> > >> Thierry > > > > -- > > Thierry Goubier > > CEA list > > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > 91191 Gif sur Yvette Cedex > > France > > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by kilon alios

Yeah I agree, this is an awesome project and thank you for your hard work :) On Mon, Nov 4, 2013 at 8:12 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: > Hi Max, > > I saw you were on it :) It's a huge effort you're undertaking. I learned a > bit about git internal storage stepping through the code. > > Thierry > > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Max > Leske [maxleske(a)gmail.com] > Date d'envoi : lundi 4 novembre 2013 17:44 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Github and Pharo > > FileSystem-Git is basically in alpha at the momentâ¦ Iâm rewriting it. > > > On 04.11.2013, at 17:04, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit > of work to do... > > > > I tried on one of my work repository, and: > > - it failed trying to uft8convert a packed data file. > > So I corrected the error (get the stream as binary!) and > > - It failed looking for one of the commit IDs > > I found the ref in a pack file; apparently, it's not looking in there... > > I'm forcing a read of the pack files in there > > - Yet another utf8convert error on binary data > > Corrected, I got the pack files, but the index isn't telling me much. > > I tried to list the objects in it... Unknown compression method error. > > > > There's a huge amount of code in there, it's a bit frightening. I think > I'll stay with OSProcess a bit longer ;) > > > > Thierry > > > > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : > >> > >> > >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : > >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: > >>>> > >>>> > >>>> Le 04/11/2013 12:11, kilon alios a ?crit : > >>>>> yeap filetree did the trick here. However it does not allow to browse > >>>>> through the git commits as gitfiletree does, the only commit > available > >>>>> is the last commit. > >>>>> > >>>>> I took a look at CommandShell and friends and they all look pretty > much > >>>>> very broken. For example in workspace I executed > >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates > an > >>>>> error because it add C path inside pharo subdirectories. Dont know if > >>>>> this is normal behavior. > >>> > >>> Use "CommandShell open" rather than "CommandShellTranscript open". > >>> > >>> > >>>> > >>>> I hope someone with more knowledge than me of OSProcess under windows > >>>> will have a look :) > >>>> > >>> OSProcess support for Windows is incomplete, so this will probably not > >>> do what you need. If the OSProcess is included in the Windows VM, it > will > >>> let you run a Windows program, but it will not do most of the other > >>> things > >>> that you expect from OSProcess. > >>> > >>> Check http://www.squeaksource.com/ProcessWrapper.html for a possible > >>> alternative. > >> > >> Thanks Dave; no easy solution on that, it seems. I'll have a look then > >> with FileSystem-Git, this one may be a more portable solution. > >> > >> Windows is still a world apart from the rest :( > >> > >> Thierry > > > > -- > > Thierry Goubier > > CEA list > > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > > 91191 Gif sur Yvette Cedex > > France > > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > > > > > >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by GOUBIER Thierry

Hi Max, I saw you were on it :) It's a huge effort you're undertaking. I learned a bit about git internal storage stepping through the code. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Max Leske [maxleske(a)gmail.com] Date d'envoi : lundi 4 novembre 2013 17:44 Ã : Pharo Development List Objet : Re: [Pharo-dev] Github and Pharo FileSystem-Git is basically in alpha at the momentâ¦ Iâm rewriting it. On 04.11.2013, at 17:04, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... > > I tried on one of my work repository, and: > - it failed trying to uft8convert a packed data file. > So I corrected the error (get the stream as binary!) and > - It failed looking for one of the commit IDs > I found the ref in a pack file; apparently, it's not looking in there... > I'm forcing a read of the pack files in there > - Yet another utf8convert error on binary data > Corrected, I got the pack files, but the index isn't telling me much. > I tried to list the objects in it... Unknown compression method error. > > There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) > > Thierry > > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : >> >> >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: >>>> >>>> >>>> Le 04/11/2013 12:11, kilon alios a ?crit : >>>>> yeap filetree did the trick here. However it does not allow to browse >>>>> through the git commits as gitfiletree does, the only commit available >>>>> is the last commit. >>>>> >>>>> I took a look at CommandShell and friends and they all look pretty much >>>>> very broken. For example in workspace I executed >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates an >>>>> error because it add C path inside pharo subdirectories. Dont know if >>>>> this is normal behavior. >>> >>> Use "CommandShell open" rather than "CommandShellTranscript open". >>> >>> >>>> >>>> I hope someone with more knowledge than me of OSProcess under windows >>>> will have a look :) >>>> >>> OSProcess support for Windows is incomplete, so this will probably not >>> do what you need. If the OSProcess is included in the Windows VM, it will >>> let you run a Windows program, but it will not do most of the other >>> things >>> that you expect from OSProcess. >>> >>> Check http://www.squeaksource.com/ProcessWrapper.html for a possible >>> alternative. >> >> Thanks Dave; no easy solution on that, it seems. I'll have a look then >> with FileSystem-Git, this one may be a more portable solution. >> >> Windows is still a world apart from the rest :( >> >> Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Nov. 4, 2013

Re: [Pharo-dev] Spaceship?

by Nicolas Cellier

we add^H^H^H had 2013/11/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Beware of cases where you don't have total order. > For example, in recent Squeak/Pharo we add to redefine the whole set of > operators on numbers, not only < and =, just because NaN is not ordered... > > > 2013/11/4 kilon alios <kilon.alios(a)gmail.com> > >> It looks to me that this would be the source of less readable code, I >> prefer the choosing message approach by Kent Beck (Smalltalk Best Practice >> Patterns) where intent is clearly stated. Unless there is an advantage I am >> missing here. This is an example that less verbose code does not mean >> simpler code. Of course this will largely depend on the specifics of the >> case used. >> >> >> On Mon, Nov 4, 2013 at 3:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: >> >>> Now she someone wantâs to have a comparable object he has to use >>> TComparable and define < and =. >>> With spaceship he has to define only <=>. Iâm not sure whatâs better. >>> Just wanted to hear other peoples opinion >>> >>> On 04 Nov 2013, at 13:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >>> > do you have a real use case? >>> > >>> > Stef >>> > >>> > On Nov 4, 2013, at 1:32 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> > >>> >> Hi everyone. >>> >> >>> >> Iâm wandering if there was any sort of a discussion about a spaceship >>> method used in Ruby. >>> >> >>> >> The concept is that you should implement a method <=> >>> >> that returns something negative if the receiver is smaller then a >>> parameter, >>> >> positive when the receiver is greater then a parameter, >>> >> and 0 if they are equal. >>> >> >>> >> This way if you are implementing comparable objectâs the only method >>> you have to redefine is spaceship (<=>). >>> >> >>> >> Yes, I know that i Pharo you have to only redefine < and =. But maybe >>> it would be interesting to use spaceship :) >>> >> >>> >> What do you think? >>> >> Cheers! >>> >> Uko >>> > >>> > >>> >>> >>> >> >

Nov. 4, 2013

Re: [Pharo-dev] Spaceship?

by Nicolas Cellier

Beware of cases where you don't have total order. For example, in recent Squeak/Pharo we add to redefine the whole set of operators on numbers, not only < and =, just because NaN is not ordered... 2013/11/4 kilon alios <kilon.alios(a)gmail.com> > It looks to me that this would be the source of less readable code, I > prefer the choosing message approach by Kent Beck (Smalltalk Best Practice > Patterns) where intent is clearly stated. Unless there is an advantage I am > missing here. This is an example that less verbose code does not mean > simpler code. Of course this will largely depend on the specifics of the > case used. > > > On Mon, Nov 4, 2013 at 3:37 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com>wrote: > >> Now she someone wantâs to have a comparable object he has to use >> TComparable and define < and =. >> With spaceship he has to define only <=>. Iâm not sure whatâs better. >> Just wanted to hear other peoples opinion >> >> On 04 Nov 2013, at 13:35, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> > do you have a real use case? >> > >> > Stef >> > >> > On Nov 4, 2013, at 1:32 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> > >> >> Hi everyone. >> >> >> >> Iâm wandering if there was any sort of a discussion about a spaceship >> method used in Ruby. >> >> >> >> The concept is that you should implement a method <=> >> >> that returns something negative if the receiver is smaller then a >> parameter, >> >> positive when the receiver is greater then a parameter, >> >> and 0 if they are equal. >> >> >> >> This way if you are implementing comparable objectâs the only method >> you have to redefine is spaceship (<=>). >> >> >> >> Yes, I know that i Pharo you have to only redefine < and =. But maybe >> it would be interesting to use spaceship :) >> >> >> >> What do you think? >> >> Cheers! >> >> Uko >> > >> > >> >> >> >

Nov. 4, 2013

Re: [Pharo-dev] flatCollect:

by Chris Cunningham

Right. I hadn't looked closely enough at the Moose one. Actually, if you dig it a bit deeper, #writeStream isn't defined in the Collection hierarchy until you get to SequenceableCollection in any case, so the Moose version is defined too high. So, if there is a desire for #flatCollect: outside of SequenceableColleciton, then this should work (based on Moose version): Collection>>flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" "original written by a. Kuhn and released under MIT" | result | self isEmpty ifTrue: [ ^ self copy ]. result := (self species new: 0). self do: [ :each | result addAll: (aBlock value: each) ]. ^ result SequenceableCollection>>flatCollect: aBlock "Evaluate aBlock for each of the receiver's elements and answer the list of all resulting values flatten one level. Assumes that aBlock returns some kind of collection for each element. Equivalent to the lisp's mapcan" "original written by a. Kuhn and released under MIT" | stream | self isEmpty ifTrue: [ ^ self copy ]. ^self species streamContents: [ :stream | self do: [ :each | stream nextPutAll: (aBlock value: each) ] -Chris On Mon, Nov 4, 2013 at 8:46 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Actually I am still confused about this, for example, > > Set new writeStream nextPut: 1; contents > > does not work, so for which non-sequenceable collections would the > #flatCollect: code work ? > > I was thinking that maybe #streamContents: could be put higher up ? > If that would not be possible, why not ? > And how would the #flatCollect: code then work ? > > On 04 Nov 2013, at 17:36, Chris Cunningham <cunningham.cb(a)gmail.com> > wrote: > > > On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Indeed, it would be more elegant, but streamContents: is only defined in > SequeanceableCollection, so it is not generic enough. > > > > So, then use the generic one where it is defined (Collection), and a > more specific one that Sven suggested in SequenceableCollection. > > > > -Chris > > > > Doru > > > > > > On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too > might needs the #species > > > > Would it also not be better and more elegant to say > > > > self species streamContents: [ :stream | > > â¦ ] > > > > ? > > > > On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > > On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > > >> Hi, > > >> > > >> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as > the method proved to be very valuable in the context of Moose. > > >> > > >> However, the current Pharo implementation is less ideal: > > >> > > >> Collection>>flatCollect: aBlock > > >> ^ Array streamContents: > > >> [:stream | > > >> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] > > >> > > >> The Moose one is: > > >> Collection>>flatCollect: aBlock > > >> "Evaluate aBlock for each of the receiver's elements and answer > the > > >> list of all resulting values flatten one level. Assumes that > aBlock returns some kind > > >> of collection for each element. Equivalent to the lisp's mapcan" > > >> "original written by a. Kuhn and released under MIT" > > >> > > >> | stream | > > >> self isEmpty ifTrue: [ ^ self copy ]. > > >> stream := (self species new: 0) writeStream. > > >> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. > > >> ^ stream contents > > >> > > >> The difference is in the type returned. The Pharo one always returns > Array, while the Moose one returns a collection of the same species as the > receiver. > > > > > > Sounds right, returning #species. > > > > > >> Does anyone have anything against the Moose implementation? > > >> > > >> Doru > > >> > > >> -- > > >> www.tudorgirba.com > > >> > > >> "Every thing has its own flow" > > > > > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > >

Nov. 4, 2013

Re: [Pharo-dev] flatCollect:

by Camillo Bruni

On 2013-11-04, at 17:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Actually I am still confused about this, for example, > > Set new writeStream nextPut: 1; contents This should actually work the same way as OrderedCollection streamContents: [ :s | s nextPut: 1 ]. or Symbol streamContents: [ :s | s nextPutAll: 'abc' ] > does not work, so for which non-sequenceable collections would the #flatCollect: code work ? > I was thinking that maybe #streamContents: could be put higher up ? > If that would not be possible, why not ? > And how would the #flatCollect: code then work ? > > On 04 Nov 2013, at 17:36, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > >> On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Indeed, it would be more elegant, but streamContents: is only defined in SequeanceableCollection, so it is not generic enough. >> >> So, then use the generic one where it is defined (Collection), and a more specific one that Sven suggested in SequenceableCollection. >> >> -Chris >> >> Doru >> >> >> On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too might needs the #species >> >> Would it also not be better and more elegant to say >> >> self species streamContents: [ :stream | >> â¦ ] >> >> ? >> >> On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the method proved to be very valuable in the context of Moose. >>>> >>>> However, the current Pharo implementation is less ideal: >>>> >>>> Collection>>flatCollect: aBlock >>>> ^ Array streamContents: >>>> [:stream | >>>> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] >>>> >>>> The Moose one is: >>>> Collection>>flatCollect: aBlock >>>> "Evaluate aBlock for each of the receiver's elements and answer the >>>> list of all resulting values flatten one level. Assumes that aBlock returns some kind >>>> of collection for each element. Equivalent to the lisp's mapcan" >>>> "original written by a. Kuhn and released under MIT" >>>> >>>> | stream | >>>> self isEmpty ifTrue: [ ^ self copy ]. >>>> stream := (self species new: 0) writeStream. >>>> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. >>>> ^ stream contents >>>> >>>> The difference is in the type returned. The Pharo one always returns Array, while the Moose one returns a collection of the same species as the receiver. >>> >>> Sounds right, returning #species. >>> >>>> Does anyone have anything against the Moose implementation? >>>> >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Nov. 4, 2013