Re: [boost] [iostreams] request for advice on naming [repost]

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-07-09 20:01:59

Rob Stewart wrote:
> From: "Jonathan Turkanis"
>> Rob Stewart wrote:

>>> You may find these a bit redundant, but what about "iostream" and
>>> "iostreambuf?"
>>
>> 'iostream' suffers the same problem as 'streambuf': it already names
>> a type in namespace std.
>
> Right.  Same problem/same opportunity to ignore until
> standardization.

If I choose to ignore the problem, I prefer 'stream' and 'streambuf.'

>>> Another approach, which I like less, but might give you an idea,
>>> is "streamer" and "streambuffer."  (Well, "streambuffer" is just
>>> fine, but I don't care much for "streamer.")
>>
>> I think I need to keep stream and streambuf as components of the
>> names, because I don't want to rename
>> filtering_stream/filtering_streambuf.
>
> Well, whatever you call generic_stream and generic_streambuf,
> can't filtering_stream and filtering_streambuf follow suit?

Yes, but I like the names filtering_stream and filtering_streambuf. Among other
things, they're close to James Kanze's original names.

>>> Maybe a departure from "stream" is in order: pipe, pipeline,
>>> formatter, ...?
>>
>> 'pipeline' is already used for the return type of expressions like
>>
>>    gzip_compressor() | base64_encoder() | file_sink(...)
>
> Yeah, I was just trying to find something that might work or
> trigger a thought in your head.

Okay. Unfortunately it hasn't happened yet ;-)

>> I may use the name 'pipe' for wrappers for operating system pipes,
>> or portable
>
> Sure.
>
>> replacements. 'formatter' seems in appropriate, since for now the
>> library handles only unformatted i/o, relying on the standard
>> iostreams library to provide a formatting layer.
>
> Agreed.
>
>> Maybe I could go Alexandrescuesque:
>>
>>     flex_stream, flex_streambuf
>
> Well, due to the PBD, they are flexible.
>
>> Or black separatist:
>>
>>    xstream, xstreambuf
>>
>> Actually, this looks pretty good. Maybe it would run afoul of the
>> prohibition against cryptic names; there's a precedent, however, in
>> xtime from Boost.Threads.
>
> The "x" can imply "extension" or "extended," so that does work
> pretty nicely.  Besides, it keeps the names short.

I think I like these.

I had another idea:

     device_stream, device_streambuf

Unlike 'stream_facade' and 'streambuf_facade,' these are perfect descriptions of
the components. They don't roll off the tongue very easily, though.

Jonathan