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

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Lee Clagett (forum_at_[hidden])
Date: 2016-11-07 07:44:49

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.

> > 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.

> 
> 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?

> >
> > This might be slightly annoying in the case of the child process 
> > executable path, though.  I don't know whether it'd be worthwhile 
> > making an exception for that case or not.  
> 
> I don't understand the problem with allowing both in the first place, 
> but you're mentioning why I added that feature. So why only for the
> exe?

Lee