Re: [gobo-eiffel-develop] indenting text output filter

[Andreas L. <ale...@ra...>]

Hi Eric,

thanks for the quick reply.

On Thu, 2007-05-24 at 11:42 +0200, Eric Bezault wrote:

> I'm just trying to find a better name. If it *is* an output stream,
> then it is not a filter. What about KL_INDENTED_TEXT_OUTPUT_STREAM
> (should it really be in the kernel library, or elsewhere (where?))?

I wanted to call it something with OUTPUT_STREAM too initially, but then
I did think it was a little more than an outputstream. It is an output
stream that forwards things slightly modified to another output stream.
Which I think is just what is also called a filter in the xml event
cluster. In fact now that I think of it, the class could be split in
two:

KL_TEXT_OUTPUT_FILTER -- just having the forwarding bits, doing no
transformation at all

KL_INDENTED_TEXT_OUTPUT_STREAM | _FILTER -- just containing the
indentation bits

Your name is intuitive and conveys the idea very well though, so if we
decide to hide the filtering metaphor, that's fine with me.


> Or should the indentation facility be part of KI_TEXT_OUTPUT_STREAM
> with an option to enable it or not? In fact we probably don't need
> an option, the fact that `indent' is never called (and hence
> `indentation' is kept to 0) should be enough. The questions are:
> is it acceptable to add 2 attributes to class KI_TEXT_OUTPUT_STREAM,
> and will the test to figure out that there is actually no indentation
> to be printed be noticeable in terms of performance?

That would actually be nice, since you don't need to build a pipeline.
On the other hand, I think a pipeline is quite intuitive and easy to
build (once you know the pattern) and it spreads the functionality so
that KI_TEXT_OUTPUT_STREAM itself is more easy to understand.

> Note your implementation is not bullet-proof. It won't work if we
> call `put_string' with an argument that contains newlines. Is that
> acceptable? If yes, it should be clearly stated.

Yeah, that's a very good point. I made it a habit of never writing
manifest newlines so it is not an issue. Processing `put_string' for
newline is a potential performance problem. So I would opt for leaving
it like it is. You are absolutely right though, we should state it in
the header comment and maybe even in the indexing clause.

Andreas