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