Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-07 08:26:11

Am 07.11.2016 um 13:44 schrieb Lee Clagett:
> On Mon, 7 Nov 2016 01:46:42 +0100
> Klemens Morgenstern <klemens.morgenstern_at_[hidden]> wrote:
>
>> Am 07.11.2016 um 01:14 schrieb Gavin Lambert:
>>> On 6/11/2016 21:30, Klemens Morgenstern wrote:
>>   [...]
>>> [...]
>>   [...]
>>> I think perhaps the request is to remove the magic inferring of
>>> purpose for external argument types (eg. that passing a std::string
>>> represents an argument... sometimes) in favour of making this
>>> explicit (arguments can only be passed via "args", either
>>> constructed inline or prepared beforehand and passed in.
>>>   
>> I didn't understand it that way, especially since he Bjorn mentioned
>> boost::thread. I'm a bit tired of this discussion, and Boris
>> explained very well, why the initializers-approach was chosen. As far
>> as I understand it he considers everything but args as attributes and
>> wants them all crammed into one type (or something like that) which
>> would be a horrific mess. I should know, I tried to build somethinke
>> like that (based on boost.process), just two ours ago - it doesn't
>> work for a proper process library, there are just too many properties
>> to a process. Also the "sometimes" is clearly defined: the first
>> string if not after an exe initializer will be interpreted as the
>> argument for exe - unless there's only one, then it's a cmd.
> I read through the explanation by Boris and the object as named
> parameters approach. The documentation never formally specifies a
> "property", or how a user could create a custom property for
> interacting with library (or did I miss this?). There is a section
> labeled "extensions" which list three functions: `on_setup`,
> `on_error`, and `on_success`. The documentation mentions no arguments
> for this functions. So how exactly do I extend this library? Did you
> mean the maintainers could add features easier? Separating different
> `properties` into unique calls would reduce the maintenance for the
> internal metaprogramming necessary for the current design.
Well there are two things: first I forgot to add the signatures for the 
extensions and the example is wrong, but with those you can start with that.

Secondly, the I'll add a part about extensions, but that is currently 
not public. The interface is easily extensible, I didn't add documention 
for that and the necessary classes are in boost::proces::detail. The 
reason is, that this part of the library might change, and I don't think 
give I can give a guarantee that I won't break your code at some point 
if you use that. I.e. I don't want to, but it may be unavoidable. I'll 
add some implementation notes for that soon.

Here's how you'd do it:

struct my_handler : boost::process::detail::handler
{
    //overload the event handlers
     template<typename Exec>
     void on_success(Executor & exec) const {cout << "it works" << endl;}
};

my_handler mh;
bp::child c("foo", mh);

And with two template specializations & one more class you can add a 
marked type, which is not directly an initializer. That's a bit mor 
complicated, but possible.

>
>>> By extension, probably the only types that the launch functions
>>> should accept are the explicit "named parameters" helper types
>>> defined in Boost.Process (or compatible extensions).
>> That's what boost.process 0.5 did, I extended that (in an also -
>> theorectically - extensible way), because I really like this syntax:
>>
>> bp::system("gcc","--version");
>>
>> while this would look sort of overdone in the same context:
>>
>> bp::system(exe="gcc", args={"--version"});
> Its worth repeating that Bjorn suggested something like:
>
>      bp::system("gcc").env(...)("--version");
>
> which does not require named parameters for the arguments properties.
Do you really want me to repeat for the 42th time why this is a bad idea?
>> This would also require additional explicit arguments, which are
>> completely unnecessary, since the type can only be used in one way,
>> those would be: group, asio::yield_context and asio::io_service.
> I do not understand this paragraph. Are you saying that requiring
> explicit `arguments properties` would affect these other properties?
well instead of writing

bp::group g;
bp::child c("foo", g);

you'd need to write

bp::group g;
bp::child c(cmd="foo", some_artificial_group_ref_name=g);