>I'm sorry that I have to add my $0.02 once again, but since this
>discussion seems to pop up again and again I'd like to present a
>simple solution which also shows why Oberon/F has ASCII-I/O already
>included.
If, as you say this discussion keeps appearing again and again, it
is because there is something wrong with the way Oberon/F handles
ASCII text file I/O. I will try again to explain what is wrong with
the way Oberon/F handles this problem. Please keep in mind your words
about a "simple solution".
>The idea is to use the Text Subsystem, i.e. TextMappers
>(Scanners/Formatters) are used to read from/write to the text model
>as usual. However, instead of loading/saving the text model as an
>Oberon/F document the text is written to a file using the built-in
>ASCII-converter. The solution is fairly simple and adds only a few
>lines of code to initialize the scanners/formatters...
>IMPORT
>TextModels, TextMappers, TextViews, Math, Files, Converters,
>Stores, DevLog;
It seems that you forgot something. You should have written that the
idea was to use the following seven modules: TextModels, TextMappers,
TextViews, Files, Converters, Stores, DevLog. Is this simple? Is this
as efficient as it could be without all these modules? Are you sure
about what these modules are really doing?
>(* these may be platform specific *)
>AsciiImporter = "HostTextConv.ImportText";
>AsciiExporter = "HostTextConv.ExportText";
Here you are revealing that the building blocks that you have
chosen are not effective to code a portable solution. Please note
that portable here has a very restrictive meaning, that is, true only
for Oberon/F.
>c := Converters.list;
>WHILE (c # NIL) & (c.imp # AsciiImporter) & (c.exp # AsciiExporter) DO
> c := c.next
>END;
Here you are revealing that a person interested only in ASCII text
file I/O will have to master the following concepts: records, pointers
and lists. However, these concepts, which incidentally are not simple,
are not enough. Your code also reveals that a little understanding
about dynamic allocation, information hiding and object orientation
would help. As I am not a computer science expert, I probably forgot
some other "simple" concepts.
I am a civil engineer and my concerns are far away from having to
code my own ASCII text file I/O module or alternatively having to
extend that ridiculous joke called ObxAscii.
I hope I was able to show that Oberon/F lacks simple ASCII text file
I/O. If OMI does not change this situation soon, I will not be
surprised if Oberon/F turns into a big failure -- what I am already
wondering considering the volume of this mailing list.
Vinicius