gobo-eiffel-develop

[gobo-eiffel-develop] indenting text output filter

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

Hi all:

I have been generating a lot of code over the years. Printing
indentation was always a messy issue. It involved lots of unreadable '%
T's.  I very much liked Eric's approach in gec where you have a tripple
of rouintes (one for increasing indentation, one for decreasing and one
for printing the current level).

I have generalized this approach now for Erl-G into an output filter. It
is a class that you put in front of your actual text output stream. This
class _is_ an outputstream with the two additional public commands of
`indent' and `detent' (better names welcome!) and transparently prints
indentation for every line to a given target output stream.

I have attached the class as it might be useful to others. Eric if you
like it please feel free to include it in Gobo.

Andreas

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

[Eric B. <er...@go...>]

Andreas Leitner wrote:
> Hi all:
> 
> I have been generating a lot of code over the years. Printing
> indentation was always a messy issue. It involved lots of unreadable '%
> T's.  I very much liked Eric's approach in gec where you have a tripple
> of rouintes (one for increasing indentation, one for decreasing and one
> for printing the current level).
> 
> I have generalized this approach now for Erl-G into an output filter. It
> is a class that you put in front of your actual text output stream. This
> class _is_ an outputstream with the two additional public commands of
> `indent' and `detent' (better names welcome!) and transparently prints
> indentation for every line to a given target output stream.
> 
> I have attached the class as it might be useful to others. Eric if you
> like it please feel free to include it in Gobo.

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?))?
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?

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.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

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

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

[Eric B. <er...@go...>]

Andreas Leitner wrote:
>> 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.

OK, so we have a "filter" that introduces indentation. Should
KI_TEXT_OUTPUT_STREAM be implemented as a filter as well, which
introduces new-lines to character output streams? It looks too
heavy to me. So, where is the border-line between having things
in the stream and other things in a filter?

Also, for example for `put_character', the header-comment is
not correct. It says nothing about the indentation. What would
have happened if assertions could have been written to explicitly
state that the character `v' and only this character was written?

I understand that the filter pattern (it should have another
name in the GoF book) is very convenient because we can add
functionalities that we didn't think about when we wrote the
class, and we can combine them together in different ways.
The question is when should a functionality be added to the
class and when should it be added to a filter.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com

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

[Bernd S. <ber...@in...>]

At Thu, 24 May 2007 13:18:20 +0200,
Andreas Leitner wrote:
> 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.

I fully agree, having the concept of output filter would be nice for
many applications. In the long run, might even consider building a
cluster of filters.

> > 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.

Hmm - I think we should keep interfaces small to make it easy to
implement new output streams. Blowing up interfaces with indentation
facilities seems wrong. Filters are the better way to go.
 
> > 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.

Best would be if we can toogle replacing newlines in strings with
'put_string' on- and off. Also, if it is off, do we need a
precondition in put_string to enforce that the string does not contain
newlines?

I would even vote for switching it on by default, because it is the
little more universal (though less efficient) choice.

Bernd