[Oberon] Cleaning up low level modules (a pipe dream)
chris at cfbsoftware.com
Fri Jun 19 23:41:18 CEST 2020
> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Jörg
> Sent: Saturday, 20 June 2020 6:35 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Cleaning up low level modules (a pipe dream)
> Your base idea is okay, but please not in ONE file. Group the constants by
> area. Eg move all ASCII constants to Input.Mod. It is really strange that
> all modules working with ASCII redefine the constants over and over again
> instead of just importing them from one central place namely, Input.Mod (I
> did that and defined also ASCII codes of the arrow keys, I can move the
> caret with the keys and not only the mouse)
Good idea. However, it would seem strange to me to have to IMPORT Input.Mod into Output.Mod, say, just to be able to access the ASCII constants. Is there any good reason not to have a common file e.g. ASCII.Mod which contains just the ASCII constants. ASCII is then imported into Input and Output and anything else that needs to access them?
One possible reason might be that the keycodes you mention, say, are only relevant to Input so why import them into Output as well? If this were an issue it might be preferable to have another common file e.g. Keys.Mod and only have the actual codes from the ASCII table in ASCII.Mod.
This is nothing new. The time spent trying to dream up 'new ideas' might be better spent studying history. So many of these sorts of problems were identified and solved many years ago. I just had a look in my Logitech Modula-2/86 Users Guide dated December 1984 and, what do you know, that has an ASCII module.
There is no excuse not to try to learn from the lessons of the past now that so much of it is documented and available on the Internet. For example, a later version of the Logitech manual I am talking about can be downloaded from:
More information about the Oberon