[Moose-dev] #deepCollect:

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

[Moose-dev] #deepCollect:

cbc
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
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Esteban A. Maringolo
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 <[hidden email]>:

> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Uko2
In reply to this post by cbc
Wow, this is really cool. I missed this while working with PP.

Thanks Chris!

Uko

On 13 Dec 2013, at 18:02, Chris Cunningham <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Frank Shearar-3
In reply to this post by cbc
On 13 December 2013 17:02, Chris Cunningham <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Tudor Girba-2
In reply to this post by 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 <[hidden email]> 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



--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Tudor Girba-2
In reply to this post by Esteban A. Maringolo
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:

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 <[hidden email]> 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 <[hidden email]>:
> 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




--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

kilon
στειλε μου την πάλι στο [hidden email] γιατί εδώ μπαίνω πλέον σπάνια και για κάποιο λόγο δεν μου κατεβάζει το αρχείο σου.  Σόρρυ που σε ξέχασα φιλαράκι αλλά αυτή την εβδομάδα δεν ήμουν και πολύ στα καλά μου. Στην είπα να την γράψεις έτσι για το τυπικό της υπόθεσης , νομικά δεν παίζει μεγάλο ρόλο απο την στιγμή που έχουν λάβει γνώση δηλαδή γνωρίζουν την περίπτωση σου. 


On Friday, 13 December 2013, 23:29, Tudor Girba <[hidden email]> 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:

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 <[hidden email]> 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 <[hidden email]>:
> 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




--

"Every thing has its own flow"


Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

kilon.alios
sorry for this i mixed up the mailing adresses :D


On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <[hidden email]> wrote:
στειλε μου την πάλι στο [hidden email] γιατί εδώ μπαίνω πλέον σπάνια και για κάποιο λόγο δεν μου κατεβάζει το αρχείο σου.  Σόρρυ που σε ξέχασα φιλαράκι αλλά αυτή την εβδομάδα δεν ήμουν και πολύ στα καλά μου. Στην είπα να την γράψεις έτσι για το τυπικό της υπόθεσης , νομικά δεν παίζει μεγάλο ρόλο απο την στιγμή που έχουν λάβει γνώση δηλαδή γνωρίζουν την περίπτωση σου. 


On Friday, 13 December 2013, 23:29, Tudor Girba <[hidden email]> 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:

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 <[hidden email]> 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 <[hidden email]>:
> 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




--

"Every thing has its own flow"



Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Tudor Girba-2
Ok, but now I am curious :).

Could you translate?

Doru


On Sat, Dec 21, 2013 at 10:26 AM, kilon alios <[hidden email]> wrote:
sorry for this i mixed up the mailing adresses :D


On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <[hidden email]> wrote:
στειλε μου την πάλι στο [hidden email] γιατί εδώ μπαίνω πλέον σπάνια και για κάποιο λόγο δεν μου κατεβάζει το αρχείο σου.  Σόρρυ που σε ξέχασα φιλαράκι αλλά αυτή την εβδομάδα δεν ήμουν και πολύ στα καλά μου. Στην είπα να την γράψεις έτσι για το τυπικό της υπόθεσης , νομικά δεν παίζει μεγάλο ρόλο απο την στιγμή που έχουν λάβει γνώση δηλαδή γνωρίζουν την περίπτωση σου. 


On Friday, 13 December 2013, 23:29, Tudor Girba <[hidden email]> 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:

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 <[hidden email]> 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 <[hidden email]>:
> 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




--

"Every thing has its own flow"






--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

kilon.alios
"Send me the document to [hidden email] 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 <[hidden email]> wrote:
Ok, but now I am curious :).

Could you translate?

Doru


On Sat, Dec 21, 2013 at 10:26 AM, kilon alios <[hidden email]> wrote:
sorry for this i mixed up the mailing adresses :D


On Sat, Dec 21, 2013 at 11:04 AM, dimitris chloupis <[hidden email]> wrote:
στειλε μου την πάλι στο [hidden email] γιατί εδώ μπαίνω πλέον σπάνια και για κάποιο λόγο δεν μου κατεβάζει το αρχείο σου.  Σόρρυ που σε ξέχασα φιλαράκι αλλά αυτή την εβδομάδα δεν ήμουν και πολύ στα καλά μου. Στην είπα να την γράψεις έτσι για το τυπικό της υπόθεσης , νομικά δεν παίζει μεγάλο ρόλο απο την στιγμή που έχουν λάβει γνώση δηλαδή γνωρίζουν την περίπτωση σου. 


On Friday, 13 December 2013, 23:29, Tudor Girba <[hidden email]> 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:

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 <[hidden email]> 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 <[hidden email]>:
> 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




--

"Every thing has its own flow"






--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Stéphane Ducasse
In reply to this post by cbc
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: [Moose-dev] #deepCollect:

Tudor Girba-2
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 <[hidden email]> 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 <[hidden email]> 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




--

"Every thing has its own flow"