XStream I think is exactly about it
2014-06-08 22:46 GMT+04:00 Camille Teruel <camille.ter...@gmail.com>:
>
> On 8 juin 2014, at 19:20, Garth Holland <steve9571...@hotmail.com> wrote:
>
> > The pipe operator appears in many languages (F#, Haskell, Elixir, Clojure
> > (threading macro)). It's an elegant way of chaining method/function
> calls in
> > the presence of additional parameters. The reddit example could be
> written
> > using a pipe operator |>
> >
> > #('apple' 'peach' 'banana')
> > |> groupedBy: #size
> > |> select: [:each | each size even]
> > |> values
> > |> collect: #asCommaString.
>
> The pipe operator is implemented as one of the examples of LanguageBox, a
> tool that permits to scope language extensions (it's a part of Helvetia
> made by Lucas Renggli).
>
> I once thought that the pipe operator could be useful. But now I notice
> that the main (if not the only) recurrent use case I found is chaining
> queries on collections.
> If you have another recurrent use case (that is not purely idiomatic :) )
> please let me know.
>
> So yes, using the pipe operator make the snippet more readable but still
> has much inefficient: at each step a new collection is created just to be
> trashed afterward.
> Here it's not a problem but not all collections only have 3 elements ;).
>
> For me it's a sign that the collection libraries lack a simple
> abstraction: composable filters (that is, iterators) to make complex
> queries.
> We could have collections answering #query that would responds a
> QueryBuilder object that would understand common enumeration methods, for
> example:
>
> #('apple' 'peach' 'banana') query
> groupedBy: #size;
> select: [:each | each size even];
> values;
> collect: #asCommaString.
>
> This would return a CollectFilter on a ValuesFilter on a SelectFilter on a
> GroupedByFilter on the input collection.
> The QueryBuilder could then answer a message like #endQuery to compute and
> return the values obtained by the lastly created filter (embedded in a
> collection that conforms to the input collection's #species).
> Since it's just a composition of filter objects over the input collection,
> no useless intermediate collection is created: better performances & less
> stress on the GC.
>
> Of course this idea is acceptable only if they are no other use cases
> where the pipe operator is a must.
>
> >
> > /Garth
> >
> >
> >
> >
> > --
> > View this message in context:
> http://forum.world.st/Pipe-operator-tp4762106p4762182.html
> > Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
> >
>
>
>
