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
On Tue Nov 25 2014 at 9:33:19 PM Henning Thielemann < lemming@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@haskell.org http://www.haskell.org/mailman/listinfo/libraries