[Pharo-dev] [Moose-dev] #deepCollect:

Tudor Girba tudor at tudorgirba.com
Sat Dec 21 05:38:10 EST 2013


Ok, but now I am curious :).

Could you translate?

Doru


On Sat, Dec 21, 2013 at 10:26 AM, kilon alios <kilon.alios at 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 at yahoo.co.uk>wrote:
>
>> στειλε μου την πάλι στο kilon.alios at gmail.com γιατί εδώ μπαίνω πλέον
>> σπάνια και για κάποιο λόγο δεν μου κατεβάζει το αρχείο σου.  Σόρρυ που σε
>> ξέχασα φιλαράκι αλλά αυτή την εβδομάδα δεν ήμουν και πολύ στα καλά μου.
>> Στην είπα να την γράψεις έτσι για το τυπικό της υπόθεσης , νομικά δεν
>> παίζει μεγάλο ρόλο απο την στιγμή που έχουν λάβει γνώση δηλαδή γνωρίζουν
>> την περίπτωση σου.
>>
>>
>>   On Friday, 13 December 2013, 23:29, Tudor Girba <tudor at 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-run/
>>
>> 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 at 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 at 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131221/02fb1957/attachment-0002.html>


More information about the Pharo-dev mailing list