MumbleCloseable goes backward

[Howard Lovatt]

On 27/06/2013, at 8:51 PM, Remi Forax <forax at univ-mlv.fr> wrote:

> On 06/27/2013 12:38 PM, Paul Sandoz wrote:
>> On Jun 27, 2013, at 12:19 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>>> A Stream should be AutoClosable or MaybeCloseable, or MaybeMaybeNotCloseable ...
>>> because using a TWR here goes in the wrong direction, the Stream API is fluent, from left to right and
>>> the TWR is right to left because you have to declare a local variable and type it (again unlike the Stream API).
>>> 
>>> So instead of:
>>>  try (Stream<Path> stream = Files.walkFile(directory)) {
>>>    stream.forEach(path -> {
>>>       ...
>>>    });
>>>  }
>>> which is an external way to manage the resources.
>>> 
>>> Because we have lambda, we should promote the internal way to manage the resources, like the rest of the Stream API,
>>> so walkFile should be written to take a Function<Stream, R>, like this:
>>>  Files.walkFile(directory, stream -> stream.forEach(path -> {
>>>    ...
>>>  });
>>> with the TWR written around the call to the function inside walkFile.
>>> 
>>> so there is *no need* for a Mumble Closeable.
>> - R could be Stream.
> 
> yes, this has to be documented, but because the result value will be a closed Stream,
> there is no issue, it will bark at first use.
> 
>> 
>> - ain't gonna work for flatMap:
>> 
>>   Files.walk(dir, sp-> sp.flatMap(p -> Files.lines(p, Function.identity()))...);
> 
> you can return void/null, no ?
> 
>> 
>> - much harder to read than:
>> 
>>   Files.walk(dir).flatMap(Files::lines)...
> 
> which leak resources.

The following wouldn't leak:

Files.walk( () -> dir ).flatMap(Files::lines)...

Because you would open the resource inside a TWR in the terminal operation, i.e. make opening a resource lazy. 

> 
>> 
>> Paul.
> 
> Rémi
>