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 19:46:42

Am 07.11.2016 um 01:14 schrieb Gavin Lambert:
> On 6/11/2016 21:30, Klemens Morgenstern wrote:
>>>> The core of my proposal is to keep attributes separate from arguments
>>>> (granted, this was not explicitly mentioned before.)
> [...]
>> 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.
>
> 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.

> 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"});

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