Stream reuse in superclass
Jose
jgetino at telefonica.net
Thu Apr 4 23:59:18 PDT 2013
Well, the first step in introducing streams in my existing code was to use
conversions
Collection--> Stream -->Collection
inside the body of existing methods, to take advantage of the stream
operations. This step leaded to a significant simplification of many
procedures.
Next step was to wonder, do really I need these collections?. Then I found
methods in my code that would admit replacing collections with streams in
their signature, leading again to a simplification of the code, because it
saved many conversions.
This procedure is what I mean for adapting old code to the streams
framework. I found it a natural way to experiment with streams,
because you already has the code and knows how it is expected to perform.
And it was a smooth path until the case that generated this thread.
The rule that I submited to your consideration would correspond to the
second step of this path: refactoring method signatures.
-----Mensaje original-----
De: David Holmes [mailto:david.holmes at oracle.com]
Enviado el: viernes, 05 de abril de 2013 7:30
Para: Jose
CC: lambda-dev at openjdk.java.net
Asunto: Re: Stream reuse in superclass
On 5/04/2013 3:22 PM, Jose wrote:
> So, if I understood you, a rule to adapt old code based on Collections to
> the new paradigm would be something like:
>
> "try to produce streams instead of collections when possible, but keep on
> consuming collections"
I'm not sure what that means.
The Stream-based API is a completely different mindset to operating
directly on Collections. I'm not sure there is a "rule" to "adapt".
David
>
>
>
> -----Mensaje original-----
> De: David Holmes [mailto:david.holmes at oracle.com]
> Enviado el: viernes, 05 de abril de 2013 3:31
> Para: Jose
> CC: lambda-dev at openjdk.java.net
> Asunto: Re: Stream reuse in superclass
>
> On 5/04/2013 6:59 AM, Jose wrote:
>> I have a class that contains a method that consumes a Stream (previously
> was
>> a Collection)
>
> And that is your problem. You can not think of operations on a stream
> the way you would a collection, as a stream is not a collection. Your
> class that operated on the elements of the collection would now become
> an operation to be passed to a suitable stream method to be applied to
> each element.
>
> David
>
>> Class Foo<T>{
>> bar(Stream<T> s){
>> .........
>> }
>> }
>>
>>
>> This method is overriden in a subclass, that first consumes the stream
and
>> then calls super
>>
>> Class PowerFoo<T> extends Foo<T>{
>> bar(Stream<T> s){
>> doImportantThingsWidth(s);
>> //now the stream is consumed :-(
>> super.bar(s)
>> }
>> }
>>
>>
>> What is the recomended way to handle situations like this?.
>>
>> Curently I'm collecting the stream into a list and getting two streams
> from
>> it.
>>
>>
>
More information about the lambda-dev
mailing list