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

Subject: Re: [boost] [process] The Formal review preiod is nearing the end
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-07 16:39:23

Am 07.11.2016 um 22:14 schrieb Nat Goodspeed:
> On Mon, Nov 7, 2016 at 12:52 PM, Klemens Morgenstern
> <klemens.morgenstern_at_[hidden]> wrote:
>
>> 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."
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.