Re: [boost] Any interest in a library for supporting program reuse?

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-01-07 12:56:19

Hi Rob,

----- Original Message ----- 
From: "Rob Stewart" <stewart_at_[hidden]>

> From what I can see, you use the term "program" to mean an
> instance of class Program or, more specifically, a derivate
> thereof.  That isn't what I think of when I see the word
> "program."

What would you suggest the name of the class be instead? It is intended to 
provide the main entry point for a program, so that the program can be 
easily reused separately.

> You cite an example in your article of piping the output of one
> *nix command to another using the output redirection operator,
> ">".  The correct operator is the pipe, "|".  You seem to have
> codified that misunderstanding, since you've overloaded ">" and
> not "|" for Program.

Thank you for pointing that out. I don't actually see a need for two 
different operators for piping and redirection within the library, except 
that it would be more appropriate for keeping with unix traditions. Ideally 
I would have one operator "|>" like in Heron.

> Finally, your Program class is too intrusive since one must
> derive from it.  It would be better if there was a make_filter()
> function template called with a function (object) returning a
> streamable object.  Then, make_filter() can return an object
> which can invoke the function(object) as necessary and can be
> chained with other instances to create a pipeline.

Why is it considered better to model a concept rather than inherit from a 
base class and override a virtual function? It seems to me that it is 
simpler to explain to a newcomer to inherit from a class, and it is more 
apparent from looking at the code what is actually happening.

> (Speaking of
> "pipeline," that is the *nix term for a series of filters piped
> together.  Hence, your PipeChain class would be better named
> "Pipeline," and its "ChainTo" member function would be better
> named "PipeTo.")

Good point.

> Oh, I should also point you to Jonathan Turkanis' IOStreams
> Library (recently accepted, but not yet added to Boost).  See
> http://home.comcast.net/~jturkanis/iostreams/ for code and
> documentation.  Look especially at the filters functionality.

I am sorry but I don't see the connection with the iostreams library and 
what I am doing. Could you explain the similarities?

Thanks for your feedback.

CD