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-06 03:30:18

Am 06.11.2016 um 01:39 schrieb Lee Clagett:
> On Sat, 5 Nov 2016 17:15:58 +0100
> Bjorn Reese <breese_at_[hidden]> wrote:
>
>> On 11/05/2016 02:47 PM, Klemens Morgenstern wrote:
>>
>>> auto c = child("foo").args("bar"). std_out(pipe).std_err(null);
>> That is not the syntax I have proposed.
>>
>> The core of my proposal is to keep attributes separate from arguments
>> (granted, this was not explicitly mentioned before.)
>>
> I'm glad you brought this up - I think Niall did as well - if you look
> at the constructor documentation for `process::child` it is very bare.
> And I am not sure how to easily describe how to use it. I think
> maintainability is going to be difficult without a more strict contract
> of expected arguments and behavior.
That is because it is one of the three launch functions, but their are 
actually quite clearly defined. You either pass a known type that will 
be intepreted as some property (i.e. std::string->args) or you pass a 
property directly, i.e. args+="Value". That is quite clear, but it is 
extensible, hence the list of actually allowed types are written in the 
reference at the properties, not in a central list.

@Bjorn: That's the syntax you would get if you used rvalue 
qualifications, as you proposed.
>> You mentioned elsewhere that you modelled bp::child after thread.
>> Boost.Thread handles attributes separate from arguments.
>>
>> The syntax for creating attributes is less important to me, although I
>> would strongly prefer a syntax where invalid attribute parameters
>> results in reasonable compiler error messages (e.g. not SFINAE
>> errors.)
>>
>>> child antlr("java");
>>> antlr("-jar", "antlr4.jar", "language.g4"); //here I'd much rather
>>> have antlr("language.g4");
>> I do not recall having imposed any constraints on how arguments are
>> collected. I would fine with something like this:
>>
>> argument with_jar = {"-jar", "antlr4.jar"};
>> antlr(with_jar, "language.g4");
> Again, I think Niall proposed something similar (callable). Also, I do
> not think partial evaluation support is necessary in boost::process
> - `boost::fit` (which I hope/think will be a boost lib) could partially
> bind command arguments or even std::bind. The syntax would be
> different, but once its a callable its much more flexible:
>
>      auto with_jar = std::bind(child("java"), "-jar", "antlr4.jar", _1);
>
> Now `with_jar` requires a single string argument to be invoked, and
> invoking it executes the process and returns a handle to that process.
>
And and why is that better then the current way of doing things?

auto antlr = [](const std::string & g4) {return child("java", "-jar", 
"antlr4.jar", g4);};
//or add an redirection:
auto antlr_p = [](const std::string & g4, pipe &p){return child("java", 
"-jar", "antlr4.jar", g4, std_out > p, std_err > null);};