[boost] Re: Re: Re: Functions as Filters (was Program Reuse...)

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-01-13 17:30:00

christopher diggins wrote:
> ----- Original Message -----
> From: "Jonathan Turkanis" <technews_at_[hidden]>
>>
>> It's not that I don't see the benefit of lower complexity; I don't
>> really see
>> the lower complexity. ;-)
>>
>> The only noticeable difference is that mine contains
>> "template<typename Source>"
>> and uses a non-member get function.
>
> And the facts that:
> 1) ToUpper() is not a non-member function

It  looks like a non-member function. Anyway, I don't see the relevance.

> 2) ToUpper() uses cin rather than a passed argument

Right, but I was suggesting that you prefered using std::cin because is avoided
the member template.

> Nonetheless consider the following psuedo-program (which does model a
> lot of software):
>
> void Fu(string s) {
>   cout << s;
> }
>
> string Bar() {
>   string ret;
>   cin >> ret;
>   return ret;
> }
>
> string Transform(string s) {
>   string ret(s);
>   // do some stuff
>   return ret;
> }
>
> void DoTransform() {
>   while (!cin.eof()) {
>     Fu(Transform(Bar()));
>   }
> }
>
> int main() {
>   DoTransform();
>   return 0;
> }
>
> Now if at a later point I want to refactor and reuse the code from a
> program like this in another, I can either rewrite the entire program
> as an iostreams filter (which is not trivial), or I can simply write (using
> my personal library):
>
> int main() {
>   fstream("in.txt") > Filter(DoTransform) > fstream("out.txt");
> }

This discussion is way off track now.

Whenever a new framework for code reuse is proposed, there are two types of
reuse to consider.

(1) Reuse of code predating the framework.
(2) Reuse of code yet to be written. Here we can assume that code intended to be
used with the framework will be designed specifically for this purpose. The
question is which patterns or concepts the framework should rely on. The ability
to reuse old code is irrelevant; what matters is which concepts or patterns are
easiest to use and most efficient.

Regarding (1), I agree that this is important, and I've indicated a willingness
to support this type of reuse several times during our discussion. All I asked
was that you show me some specific examples of old code which could be quickly
modified to conform to your filter concept. So far you haven't done so.

Regarding (2), I wanted to see a specific filtering operation which could be
expressed clearly using a co_filter but was awkward to express using one of the
existing filter concepts. Daniel James has now given an example of this.

Best Regards,
Jonathan