process: Confusion about UseHandle handles being closed.

[Edward Kmett]

FWIW- I have no problem with exporting anything you like from the
`.Internals` module, especially if it is being exported form there rather
than System.Process.

Ultimately, that is what such modules are for, they can let you violate
overly enthusiastic attempts at encapsulation until a better design can be
locked in.

So, +1.

I also have no problem with having a longer term discussion about a better
design for the main System.Process API, but I'd not let that block the two
line patch that just fixes the problem for now.

-Edward


On Wed, Nov 26, 2014 at 12:26 AM, Michael Snoyman <michael at snoyman.com>
wrote:

>
>
> On Tue Nov 25 2014 at 9:33:19 PM Henning Thielemann <
> lemming at henning-thielemann.de> wrote:
>
>>
>> On Tue, 25 Nov 2014, Felipe Lessa wrote:
>>
>> > On 25-11-2014 08:39, Henning Thielemann wrote:
>> >>
>> >> I think the cleanest solution would be to add a new field (e.g.
>> >> leaveOpen) to the CreateProcess record. (Btw. why are the other fields
>> >> named with underscores?) Otherwise, every new switch to createProcess
>> >> multiplies the number of its variants. Users who create the
>> >> CreateProcess structure using 'shell' and 'proc' won't need to adapt
>> >> their code.
>> >
>> > This would require a major version bump to the library.  It may not be
>> > worthy for such a small change.
>>
>> The small change "adding createProcess_" is the start of a messy path.
>>
>> The future proof solution would be to make the CreateProcess record opaque
>> and provide setter functions for it. I don't think there is a need to read
>> fields of CreateProcess. This change would also justify a major version
>> bump. In a first step, the 'process' package could only provide new setter
>> functions (without underscores).
>>
>>
> I read this as saying createProcess_ is not a good long-term solution, and
> instead we should strive for the most ideal long-term goal. The problem
> with this is that it makes it very difficult to have a clean migration
> path. Every time we have a breaking change- especially in a package like
> process which cannot be easily upgraded[1]- it makes it incredibly
> difficult to maintain software against multiple versions.
>
> So I'd argue that:
>
> 1. If we want to have a discussion about radically changing the API, let's
> have that discussion, but include a very clear set of plans for migration.
> Henning: have you given that any thought?
> 2. Let's not let such a discussion derail the possibility of a one-line
> patch which is very much backwards-compatible and simply avoids the need
> for people to reach for the .Internal module.
>
> Michael
>
> [1] https://www.fpcomplete.com/blog/2014/05/lenient-lower-bounds
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141126/9a53d7cc/attachment-0001.html>