Re: [boost] [process] The Formal review preiod is nearing the end

7 Nov 2016


      Am 07.11.2016 um 22:14 schrieb Nat Goodspeed:
...
On Mon, Nov 7, 2016 at 12:52 PM, Klemens Morgenstern
 wrote:
...
...
* 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
Am 07.11.2016 um 21:09 schrieb Nat Goodspeed:
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."
As stable as the library, since it is using it ;).
...
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.
Sure, makes sense. Or I just put everything into 
boost::process::extensions and declare the whole namespace as experimental.