Using the advanced features of Oberon/F it is possible to use the same I/O
methods for simple ASCII, RTF or even output to a compound document. It is even
possible to support and use converters that haven't even been written yet (such
as HTML output) if one sticks to the I/O methods of the framework.
I don't see any reason to include support for a simple subset (such as ASCII
I/O)
just because it is simple to use. That's never been the goal of a framework.
There are many programming languages that provide powerfull and simple I/O
features (such as Perl) but they are far from being that extensible as a
framework.
The question is therefore whether you want to use a framework (and accept the
fact that the complexity is higher) or if you want to use a simple library
that does exactly what the designer had in mind. If you prefer the simple
solution then why use a framework anyway...
In my opinion it would be sad if there was an ASCII I/O module for Oberon/F.
If I receive a program that was written using this module then I as a user don't
have the choice anymore to save the document in the way I want it to be saved.
What if I would prefer an RTF output by the same program? Do I have to rewrite
portions of the program to support the advanced formatting features of RTF?
What if I'm not a programmer? What if the sources are not available?
What if I would like to insert an OLE or OpenDoc object into the file?
If you decide to use the framework (and use all the features of it, e.g. hyper-
links, boldface text, etc. pp.) then the user can decide what output he wants.
Downsizing is easy, upsizing is impossible, therefore please stop the madness
and give the user a chance to decide what output (s)he wants.
Bruno