I've been following the hotly debated thread on ASCII I/O and, quite
frankly, I'm puzzled over it. Oberon/F _has_ built-in ASCII converters,
and they work fine for me. Specifically, from the dialog for opening/
saving files there is combo box (lower left corner) that allows you
to choose a converter when reading/writing a file. The default is
the document format of Oberon microsystems. Also included are two,
different, ASCII formats, HEX for data, and the ETH Oberon format.
In other words, the folks at Oberon microsystems have insulated us,
the users, from the underlying OS as much as they possibly can. I can,
for example, create a document in Oberon/F, store it as an ASCII file
(i.e., a .txt extension), and then load this file into another application
like NotePad where it is read in as a standard ASCII file; hence, my
puzzlement over this debate. It is my understanding that the Oberon-by-
Example ASCII converter is given as an abreviated example of how one can
create another file converter, e.g., RIF, that doesn't exist and they
need, i.e., an example of framework extensibility.
Beyond the capabilities provided in modules Files and Stores, and the
MVC frameworks for Text and Forms, I do not see where Oberon/F is lacking
in, for example, ASCII I/O. Please enlighten me if I'm in error.
Maybe I'm naive, but I see this escalated debate as being caused by
individuals who do not know all that Oberon/F has to offer, i.e., either a
documentation or a reading of documentation problem. Learning Oberon/F
does require time and dedication, as does learning anything of value.
Having said this, it is precisely because of the short (relatively
speaking) learning curve that I was originally attracted to Oberon.
Since then, I have had more positive experiences than negative ones,
further justifying my selection of Oberon-2 for programming, both OO
and procedural, and of Oberon/F for my development environment.
Marc, if you'll forgive me, I post your feedback to me in a recent
message addressed to me over this issue to illustrate the above point.
>>Now, as for ASCII I/O. Are you aware that you can read-from and
>>write-to ASCII files by choosing the file-name extension .txt?
>
>Hmmm, no I wasn't aware of that. I thought you had to use a "Converter" to
>open and close a text file. At least, that's what I'm doing, and that's what
>Oberon Microsystem's example and instructions says (or *said* in earlier
>versions...)
>
>>If so, I'm now confused as to what your ASCII I/O module offers over
>>Files and Stores. Can you explain - remember I'm an engineer.
>
>Don't Files and Stores just do Binary I/O? I thought TextMappers was the
>only thing that did formatted text I/O...
>
>And technically, my ASCII I/O module *does not* offer any added
>functionality over what OM provides...it just repackages OM's stuff into
>something I'm more familiar with --mine has exactly the same procedure names,
>parameters, and functionality as the ASCII I/O library I created when I was
>using an ISO Modula-2 compiler. :-) I realize that this of course is of no
>interest to anyone else, but it saved me from having to adapt large chunks of
>code to Oberon Microsystems I/O libraries.
>
>Also, my libraries "behave" a bit differently than Oberon Microsystems, but
>again this is my own personal preference. For example:
>
> 1) Mine considers EOL characters to be significant, while ignores tabs. OM
> either ignores both or pays attention to both.
> 2) My "Read Identifier" allows underscores, theirs does not.
> 3) Mine has a "Read an entire line" procedure, theirs does not.
> 4) My "Read Real" will read a sequence of numbers without a decimal
> point, while theirs would insist that this is an integer, not a real...
>:-)
> 5) Mine has a "WriteReal" option which fills the specified width with as
>many
> significant digits which will fit, while theirs requires specifying the
>number
> of places after the decimal point.
>
>So as you can see, all of this simply falls into the catagory of personal
>preference, not real added functionality. However, the person who was
>complaining was an engineer, and probably finds Oberon Microsystem's
>'TextMappers' library a bit too foreign for him -- probably a simple
>repackaging of it and avoiding riders, scanners, object-orientedness,
>converters, and instead using old-fashioned files and simple procedure calls
>is what he wants (which is essentially what my library does as well!). I
>believe another engineer did this very same thing for V4 -- at least, I think
>I read about this in comp.lang.oberon not too long ago...
>
>Marc
I hope this adds a positive spin to this topic.
Al
________________________________________________________________
| |
| Alan D. Freed Computational Materials Laboratory, MS 105-1 |
| Email: Alan.D.Freed@lerc.nasa.gov NASA Lewis Research Center |
| http://sarah.lerc.nasa.gov/~al 21000 Brookpark Road |
/) Tel: (216) 433-8747 Cleveland, OH 44135-3191 (\
/ ) Fax: (216) 433-5033 The United States ( \
_( (|_________________________________________________________________) )_
(((\ \) /,) / ) / /)))
(\\\\ \_/ / Please note \ \_/ ////)
\ / new Email address. \ /
\ _/ \_ /
----/ /--------------------------------------------------------------\ \----
/ / \ \