In order to avoid confusion with the short-term discussion, I've renamed the subject. On Wed Nov 26 2014 at 10:16:09 AM Henning Thielemann < lemming@henning-thielemann.de> wrote:
On Wed, 26 Nov 2014, Michael Snoyman wrote:
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?
As I have written, a first step into the right direction could be setter functions for CreateProcess. Another step could be to export createProcess_, but give a warning in the documentation, that it is only a temporary solution. Alternatively you could add CreateProcess_, an opaque equivalent of CreateProcess, according setter functions, and createProcess_ which accepts CreateProcess_ as input. Or you generalize createProcess using a type class, such that it both accepts CreateProcess and CreateProcess_ as input. However this might make CreateProcess_ a long term solution. Alternatively, you could add a new module that provides an opaque CreateProcess record with setter functions and an according createProcess function.
These are good proposals. I think I most like the idea of an alternate module, as it has a number of benefits: 1. We can immediately experiment with it in a separate package that has a release cycle detached from process itself. 2. There's a clear migration path: at some point we deprecate the current module in favor of the new module, and eventually replace the current module with the new one. 3. We can do a fair amount of this in a very backwards-compatible manner. One thing that I think it unclear is what the *goal* of the new module is. I've seen three things mentioned: 1. Making the CreateProcess an abstract type/moving to setters. 2. Changing the behavior of createProcess to not automatically close Handles (controlled by a leaveOpen field/setter). 3. Replace the underscore naming scheme with camel case. I just want to make sure we're explicit about the goals we have here. Given that we take things slowly enough to avoid migration headaches, I'm fully in favor of (1), and if we're already going to be breaking the API with new setters, I'm also behind (3). I'm tentatively in favor of (2) as I think the current default is broken, but I'm concerned about introducing silent breakage for people expecting the current behavior. That said, if we're changing the API anyway, there likely won't be anything silent occurring. Michael