Oberon/Naming

From Wikibooks, open books for an open world
Jump to navigation Jump to search

Conventions for names of constants, variables, types, procedures, functions and modules are in the Oberon language FAQ.

Files, Servers and Viewers[edit | edit source]

In The Oberon System; User Guide and Programmer's Manual, p. 42, Martin Reiser stated,

2.7 Naming

Oberon provides structured names to identify objects such as files, servers and viewers. The syntax of names is:
Name = NamePart { "." NamePart }
NamePart = Letter { Letter | Digit }

Why such primitive syntax? Readability an obvious factor. Security an intrepid actor. Linux file names illustrate.

Context in A2[edit | edit source]

A2 has the Oberon subsystem. The necessity to distinguish the name of a module of the subsystem from the name of a module of A2 was addressed in "Proposal for Modules Contexts" by F. Friedrich and F. Negele. The syntax to prevent name conflict is in Active Oberon[1].

Module := 'MODULE' [TemplateParameters] Identifier ['IN' Identifier] ';' ...

Hence this example.

MODULE System IN Oberon;

By convention only, the file may be named with the identifiers separated by ".". Hence the file name for the preceding example is "Oberon.System.Mod".

A2 also has conventions for file name extensions relating to target systems.

Context in General[edit | edit source]

In a syntax lacking context, an identifier in a comment may help to explain module usage.

Module := 'MODULE' Identifier '(* IN' Identifier '*);' ...

The Oberon filesystem does not support folders but the name of a file containing a module source can differ from the name of the module. Therefore file name conflict can be avoided by prefixing.

NameOfModuleFile := Identifier Identifier '.Mod'

In ETH Oberon for example, jdEdit.Mod would suggest that J. Doe had revised the Edit module from a release.

  1. Refer to the Oberon (2019) Language Report(PDF), section 5 Modules.