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
_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries