Re: [boost] [process] A doubt about private constructors

From: Julio M. Merino Vidal (jmmv84_at_[hidden])
Date: 2006-08-24 15:57:07

On 8/24/06, Jeff Garland <jeff_at_[hidden]> wrote:
> Julio M. Merino Vidal wrote:
> > Hello everybody,
> >
> > At the moment, some objects in the preliminary Boost.Process library
> > are only constructed internally by the library.  Examples of these
> > include 'status' instances, created by calls to 'child::wait', and
> > instances of 'child', created by 'launcher::start'.  This is currently
> > done by declaring friendship among the related classes (well, not
> > exactly, but almost).
> >
> > I believe this is suboptimal because it prevents extensibility.
> > Consider a user that wants to create his own Launcher implementation.
>
> What would be the motivation for providing this?

Consider, for example: somebody might want to construct a launcher
that does the minimum things for maximum efficiency.  E.g. if I don't
want to redirect any streams, I can construct a launcher that does not
do anything about them.

> > His code is required to return a new 'child' object.  But, oh!  He
> > cannot currently create it because the constructor is private and his
> > launcher class is not a friend of the provided 'child'.  Of course, he
> > could implement his own 'child' -- and in turn implement his own
> > 'status'.  Ouch.
>  >
>  >...snip details...
>  >
> > I'm open to other suggestions.
>
> I guess my thought is that if you want extensibility, just make the
> constructors public and move on.  That's the cleanest and easiest way...

That still leaves the question on what to do with all those parameters
whose type is a class in the detail namespace:

   child(handle_type h,
         detail::file_handle fhstdin,
         detail::file_handle fhstdout,
         detail::file_handle fhstderr);

Certainly, I'd rather not expose things as detail::file_handle from
this library.  Making them public means a bigger public API that must
be revised and polished, and these classes do not really belong to
Boost.Process.

So for now maybe it's better to just forget about this issue and keep
the constructors private.  They can always be made public afterwards
without breaking compatibility.

Cheers,

-- 
Julio M. Merino Vidal <jmmv84_at_[hidden]>
The Julipedia - http://julipedia.blogspot.com/