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

Am 07.11.2016 um 13:44 schrieb Lee Clagett:

On Mon, 7 Nov 2016 01:46:42 +0100 Klemens Morgenstern 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);