On Mon, Nov 7, 2016 at 12:52 PM, Klemens Morgenstern
Am 07.11.2016 um 21:09 schrieb Nat Goodspeed:
* any_initializer could still be used with any templated initializer type. Isn't that still true?
You're right, those were templated too. BUT the executor was actually not a template, so you could've written on_success(windows::executor& e). That is now different. I don't know how a type erasure could be done here, but I could write a variant. The reason is, that some properties/initializers require access the the sequence, mainly to obtain the reference of the io_service.
Please try that? I want a custom initializer to be able to access such things too.
* Klemens states that the machinery needed to write custom initializers is currently in the detail namespace. I want it to be promoted out of the detail namespace: I want support for custom initializers to be a documented, supported feature of the library. If the library is not yet "done" in that respect, then let's consider it again when it's more fully baked.
Ok, so you have three things you can do: use custom handler for events, as in
child c("foo", on_error([](auto & exec, const std::error_code & ec){std::cerr << ec.message() << std::endl;});
which is already public & documented (or at least mentioned in the documentation).
I saw that, but was misled by the fact that the documentation showed a nullary lambda. In any case I'm more interested in a custom initializer that can self-consistently intercept more than one such event.
Secondly there is the basic inheritance of "handler" (currently private, but needlessly so)
struct foo : boost::process::detail::handler { template<typename Exec> void on_error(Exec & exec, const std::error_code & ec) { std::cerr << ec.message() << std::endl;} }; };
foo f; child c("foo", foo);
This has additional features like async_handler, where you can write an on_exit handler etc. and there's a function which get's the passed io-service; so it's a bit more rich than in 0.5.
Good! I think you're saying that this feature is stable? Let's just move it out of "detail."
Now the third option (and most complicated) would be that you declare a tag for a type, provide a builder and a initializer. I won't explain that here in detail, but let's say "foo" can be internally constructed from a sequence of "bar".
The reason this is not public, is because I'm not sure what should be public and what not and I'm not sure if it works as a public interface the way it does internally. I think that needs some experience from someone other than me, actually implementing an extension, to know that. I didn't think that it would've been the best idea to put this in the version of the library to be reviewed, especially since I need the experience of someone else. I really think it makes much more sense to get the library accepted in its structure before we - and by we I mean me and a user, e.g. you, - work out the details of the public extension interface.
Then may I suggest a namespace like "experimental" (borrowing a convention used in recent C++ documents)? My expectation from other Boost libraries is that I am explicitly supposed to avoid namespace "detail." The connotation is: hands off! "experimental" suggests "API is still unstable" while leaving the feature open for user testing.