process: Confusion about UseHandle handles being closed.

Michael Snoyman michael at snoyman.com
Wed Nov 26 05:26:59 UTC 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20141126/8d6e3cb9/attachment.html>


More information about the Libraries mailing list