alternative implementations of Iterable and MapStream

[Brian Goetz]

We toyed with this as well and had some concerns about the approach. 
Since you claim this approach "has no remaining drawbacks", can you 
outline the list of drawbacks you started with?

On 5/11/2012 1:00 PM, Peter Levart wrote:
> Hello lambdanians,
>
> I toyed a little more with the idea of using "push" processing instead of
> traditional "pull" that is used in current implementations of stream
> transformation methods of Iterable and MapStream.
>
> It turned out that it can be done and that this approach has a benefit of
> avoiding box/unbox-ing of pairs of values into/out of BiValue while actualy
> having no drawbacks (I managed to elliminate all drawbacks of my 1st
> implementation from a week ago).
>
> If you are interested, have a look at:
>
> https://github.com/plevart/PushPipes
>
> Basic classes are:
>
> Producable - which implements Iterable (only as a facade)
> MapProducable - which implements MapStream (only as a facade)
>
> both classes override all defenders from Iterable and MapStream with their own
> "push" implementations.
>
> Currently Producable/MapProducable are abstract classes, but they could easily
> be transformed into interfaces with defender methods.
>
>
> Regards,
> Peter
>