Hi. I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic. My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default. If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ . -cbc
To avoid such kind of situations I would implement all the traversal methods as a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block. E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix. Regards, (*)I did that for years and in the long term it hits you back. Esteban A. Maringolo 2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
Hi Esteban, Indeed, I pondered on the issue of extending Object with the deep* methods. In the end, I chose to extend it because traversals are not a cherry on top, they are rather essential for significant analysis.
From my point of view, Pharo has to become a platform in which understanding and manipulating objects is an essential concern. The reason is that in the long run, it is precisely assessment-related activities that account for the largest development costs. I detailed a bit this idea here: http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-ru...
For this we need a powerful toolkit that makes crafting custom analyses cheap, and traversals has a prominent place in it. Cheers, Doru On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
To avoid such kind of situations I would implement all the traversal methods as a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block.
E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock
I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix.
Regards,
(*)I did that for years and in the long term it hits you back. Esteban A. Maringolo
2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com "Every thing has its own flow"
ÏÏειλε Î¼Î¿Ï Ïην Ïάλι ÏÏο kilon.alios@gmail.com γιαÏί ÎµÎ´Ï Î¼ÏÎ±Î¯Î½Ï ÏλÎον ÏÏάνια και για κάÏοιο λÏγο δεν Î¼Î¿Ï ÎºÎ±Ïεβάζει Ïο αÏÏείο ÏÎ¿Ï .  ΣÏÏÏÏ ÏÎ¿Ï Ïε ξÎÏαÏα ÏιλαÏάκι αλλά Î±Ï Ïή Ïην εβδομάδα δεν Î®Î¼Î¿Ï Î½ και ÏÎ¿Î»Ï ÏÏα καλά Î¼Î¿Ï . ΣÏην είÏα να Ïην γÏάÏÎµÎ¹Ï ÎÏÏι για Ïο ÏÏ ÏÎ¹ÎºÏ ÏÎ·Ï Ï ÏÏθεÏÎ·Ï , νομικά δεν Ïαίζει μεγάλο ÏÏλο αÏο Ïην ÏÏιγμή ÏÎ¿Ï ÎÏÎ¿Ï Î½ λάβει γνÏÏη δηλαδή γνÏÏÎ¯Î¶Î¿Ï Î½ Ïην ÏεÏίÏÏÏÏη ÏÎ¿Ï . On Friday, 13 December 2013, 23:29, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Esteban, Indeed, I pondered on the issue of extending Object with the deep* methods. In the end, I chose to extend it because traversals are not a cherry on top, they are rather essential for significant analysis.
From my point of view, Pharo has to become a platform in which understanding and manipulating objects is an essential concern. The reason is that in the long run, it is precisely assessment-related activities that account for the largest development costs. I detailed a bit this idea here: http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-ru...
For this we need a powerful toolkit that makes crafting custom analyses cheap, and traversals has a prominent place in it. Cheers, Doru On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote: To avoid such kind of situations I would implement all the traversal methods as
a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block.
E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock
I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix.
Regards,
(*)I did that for years and in the long term it hits you back. Esteban A. Maringolo
2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Â Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). Â I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. Â The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. Â I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com "Every thing has its own flow"
sorry for this i mixed up the mailing adresses :D On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
ÏÏειλε Î¼Î¿Ï Ïην Ïάλι ÏÏο kilon.alios@gmail.com γιαÏί ÎµÎ´Ï Î¼ÏÎ±Î¯Î½Ï ÏλÎον ÏÏάνια και για κάÏοιο λÏγο δεν Î¼Î¿Ï ÎºÎ±Ïεβάζει Ïο αÏÏείο ÏÎ¿Ï . ΣÏÏÏÏ ÏÎ¿Ï Ïε ξÎÏαÏα ÏιλαÏάκι αλλά Î±Ï Ïή Ïην εβδομάδα δεν Î®Î¼Î¿Ï Î½ και ÏÎ¿Î»Ï ÏÏα καλά Î¼Î¿Ï . ΣÏην είÏα να Ïην γÏάÏÎµÎ¹Ï ÎÏÏι για Ïο ÏÏ ÏÎ¹ÎºÏ ÏÎ·Ï Ï ÏÏθεÏÎ·Ï , νομικά δεν Ïαίζει μεγάλο ÏÏλο αÏο Ïην ÏÏιγμή ÏÎ¿Ï ÎÏÎ¿Ï Î½ λάβει γνÏÏη δηλαδή γνÏÏÎ¯Î¶Î¿Ï Î½ Ïην ÏεÏίÏÏÏÏη ÏÎ¿Ï .
On Friday, 13 December 2013, 23:29, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Esteban,
Indeed, I pondered on the issue of extending Object with the deep* methods. In the end, I chose to extend it because traversals are not a cherry on top, they are rather essential for significant analysis.
From my point of view, Pharo has to become a platform in which understanding and manipulating objects is an essential concern. The reason is that in the long run, it is precisely assessment-related activities that account for the largest development costs. I detailed a bit this idea here:
http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-ru...
For this we need a powerful toolkit that makes crafting custom analyses cheap, and traversals has a prominent place in it.
Cheers, Doru
On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
To avoid such kind of situations I would implement all the traversal methods as a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block.
E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock
I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix.
Regards,
(*)I did that for years and in the long term it hits you back. Esteban A. Maringolo
2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com
"Every thing has its own flow"
Ok, but now I am curious :). Could you translate? Doru On Sat, Dec 21, 2013 at 10:26 AM, kilon alios <kilon.alios@gmail.com> wrote:
sorry for this i mixed up the mailing adresses :D
On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
ÏÏειλε Î¼Î¿Ï Ïην Ïάλι ÏÏο kilon.alios@gmail.com γιαÏί ÎµÎ´Ï Î¼ÏÎ±Î¯Î½Ï ÏλÎον ÏÏάνια και για κάÏοιο λÏγο δεν Î¼Î¿Ï ÎºÎ±Ïεβάζει Ïο αÏÏείο ÏÎ¿Ï . ΣÏÏÏÏ ÏÎ¿Ï Ïε ξÎÏαÏα ÏιλαÏάκι αλλά Î±Ï Ïή Ïην εβδομάδα δεν Î®Î¼Î¿Ï Î½ και ÏÎ¿Î»Ï ÏÏα καλά Î¼Î¿Ï . ΣÏην είÏα να Ïην γÏάÏÎµÎ¹Ï ÎÏÏι για Ïο ÏÏ ÏÎ¹ÎºÏ ÏÎ·Ï Ï ÏÏθεÏÎ·Ï , νομικά δεν Ïαίζει μεγάλο ÏÏλο αÏο Ïην ÏÏιγμή ÏÎ¿Ï ÎÏÎ¿Ï Î½ λάβει γνÏÏη δηλαδή γνÏÏÎ¯Î¶Î¿Ï Î½ Ïην ÏεÏίÏÏÏÏη ÏÎ¿Ï .
On Friday, 13 December 2013, 23:29, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Esteban,
Indeed, I pondered on the issue of extending Object with the deep* methods. In the end, I chose to extend it because traversals are not a cherry on top, they are rather essential for significant analysis.
From my point of view, Pharo has to become a platform in which understanding and manipulating objects is an essential concern. The reason is that in the long run, it is precisely assessment-related activities that account for the largest development costs. I detailed a bit this idea here:
http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-ru...
For this we need a powerful toolkit that makes crafting custom analyses cheap, and traversals has a prominent place in it.
Cheers, Doru
On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
To avoid such kind of situations I would implement all the traversal methods as a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block.
E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock
I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix.
Regards,
(*)I did that for years and in the long term it hits you back. Esteban A. Maringolo
2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
"Send me the document to kilon.alios@gmail.com because here (yahoo mail) I rarely log in and for some strange reason it has not properly attached your file. Sorry for forgetting to reply to you earlier on my dear friend but this week I was not in the best mood. I told to compose the document this way to be more formal, legally it plays a minor role as long as they are aware of your case". I am a greek lawyer and I was helping a friend to create a letter for his employer for a potential promotion. Yahoo mail has changed recently its interface and it now collapses messages , without being aware it has collapsed the a moose message bellow my friend's message (saw them as "unclassified" ) and went I hit reply I was replying to this thread instead of his own message. I am now in process of migrating to gmail cause yahoo mail became to messy for me. On Sat, Dec 21, 2013 at 12:38 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Ok, but now I am curious :).
Could you translate?
Doru
On Sat, Dec 21, 2013 at 10:26 AM, kilon alios <kilon.alios@gmail.com>wrote:
sorry for this i mixed up the mailing adresses :D
On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <thekilon@yahoo.co.uk
wrote:
ÏÏειλε Î¼Î¿Ï Ïην Ïάλι ÏÏο kilon.alios@gmail.com γιαÏί ÎµÎ´Ï Î¼ÏÎ±Î¯Î½Ï ÏλÎον ÏÏάνια και για κάÏοιο λÏγο δεν Î¼Î¿Ï ÎºÎ±Ïεβάζει Ïο αÏÏείο ÏÎ¿Ï . ΣÏÏÏÏ ÏÎ¿Ï Ïε ξÎÏαÏα ÏιλαÏάκι αλλά Î±Ï Ïή Ïην εβδομάδα δεν Î®Î¼Î¿Ï Î½ και ÏÎ¿Î»Ï ÏÏα καλά Î¼Î¿Ï . ΣÏην είÏα να Ïην γÏάÏÎµÎ¹Ï ÎÏÏι για Ïο ÏÏ ÏÎ¹ÎºÏ ÏÎ·Ï Ï ÏÏθεÏÎ·Ï , νομικά δεν Ïαίζει μεγάλο ÏÏλο αÏο Ïην ÏÏιγμή ÏÎ¿Ï ÎÏÎ¿Ï Î½ λάβει γνÏÏη δηλαδή γνÏÏÎ¯Î¶Î¿Ï Î½ Ïην ÏεÏίÏÏÏÏη ÏÎ¿Ï .
On Friday, 13 December 2013, 23:29, Tudor Girba <tudor@tudorgirba.com> wrote: Hi Esteban,
Indeed, I pondered on the issue of extending Object with the deep* methods. In the end, I chose to extend it because traversals are not a cherry on top, they are rather essential for significant analysis.
From my point of view, Pharo has to become a platform in which understanding and manipulating objects is an essential concern. The reason is that in the long run, it is precisely assessment-related activities that account for the largest development costs. I detailed a bit this idea here:
http://www.humane-assessment.com/blog/choose-your-technology-for-the-long-ru...
For this we need a powerful toolkit that makes crafting custom analyses cheap, and traversals has a prominent place in it.
Cheers, Doru
On Fri, Dec 13, 2013 at 6:17 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
To avoid such kind of situations I would implement all the traversal methods as a) Traits or b) Class side methods of DeepTraversal (you choose the name) to which you'll have to pass the collection and the block.
E.g. DeepTraversal deep: aCollection do: aBlock DeepTraversal flatten: aCollection thenDo: aBlock
I, personally, don't like adding methods to Object unless it's unavoidable(*). And in those cases I choose to prefix them with something that is separate from the semantic, usually the package/framework prefix.
Regards,
(*)I did that for years and in the long term it hits you back. Esteban A. Maringolo
2013/12/13 Chris Cunningham <cunningham.cb@gmail.com>:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Every thing has its own flow"
Wow, this is really cool. I missed this while working with PP. Thanks Chris! Uko On 13 Dec 2013, at 18:02, Chris Cunningham <cunningham.cb@gmail.com> wrote:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
On 13 December 2013 17:02, Chris Cunningham <cunningham.cb@gmail.com> wrote:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
What about flattening during the parse, with #flatten? frank
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
Hi Chris, This is funny :). I took a look at your code, and if you remove your extensions on Collection, the code using deepCollect: and deep:do should work pretty much the same way. Cheers, Doru On Fri, Dec 13, 2013 at 6:02 PM, Chris Cunningham <cunningham.cb@gmail.com>wrote:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com "Every thing has its own flow"
Hi chris I think that it would be great if: - your api is compatible with the one of doru - that we can introduce your extension to Pharo - keep the package of doru outside because it is larger. With such approach we could get a first version with your code and a larger one with the one of doru and people would love it on demand. Stef On 13 Dec 2013, at 18:02, Chris Cunningham <cunningham.cb@gmail.com> wrote:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
As I mentioned before, his API is a particular case of the DeepTraverser and it is covered out of the box with the DeepTraverser implementation. But, keep in mind that Chris's deepCollect: works only for collections, while mine works for any object as starting point. Also, the DeepTraverser package has 427 lines of code (including comments), so I would say it is not quite that large :). It would be great to have it added to Pharo (actually that was the original intention). Cheers, Doru On Tue, Dec 24, 2013 at 6:26 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi chris
I think that it would be great if: - your api is compatible with the one of doru - that we can introduce your extension to Pharo - keep the package of doru outside because it is larger.
With such approach we could get a first version with your code and a larger one with the one of doru and people would love it on demand.
Stef
On 13 Dec 2013, at 18:02, Chris Cunningham <cunningham.cb@gmail.com> wrote:
Hi.
I was reading with interest the blog post on Traversal-enabled objects ( http://www.humane-assessment.com/blog/traversal-enabled-pharo-objects ) when I noticed the method #deepCollect: referenced. Interestingly, I have a method called #deepCollect: that is use (wtih related methods like #deepDo: and #deepSelect:). I suspect these uses may be compatible, with the traveral versions being more generic.
My set of #deep methods allow arbitrary flattening of collections. The #flatCollect: suite in Pharo today flattens objects 1 level; the #deepCollect: flattens the collections as many levels deep as they are nested. I found this to be a really useful ability when I work with PetitParser parsings, which tend give back massively nested Arrays by default.
If you are interested, it is published at: http://www.smalltalkhub.com/#!/~cbc/DeepCollection/ .
-cbc
-- www.tudorgirba.com "Every thing has its own flow"
participants (8)
-
Chris Cunningham -
dimitris chloupis -
Esteban A. Maringolo -
Frank Shearar -
kilon alios -
Stéphane Ducasse -
Tudor Girba -
Yuriy Tymchuk