Comparison of Oberon-2 with Modula-2
This is a short summary of the main features offered
by the programming language Oberon-2.
The target audience is the Modula-2 programmer unfamiliar with Oberon-2,
but familiar with object-oriented and extensible programming concepts.
Compared with its predecessor Modula-2,
Oberon-2 has increased expressiveness and safety.
Oberon-2 also "adds simplicity", because there are
The latter saves a great deal of software maintenance,
since the interface specification of a module is generated
by a tool from the symbol file.
Subranges and unsigned types in Modula-2 complicated the whole-number type compatibility rules
without adding any important functionality.
Program language design is a compromise and it is disputable,
whether enumeration types increase readability or static program safety.
This is an often discussed feature, but the least important.
If the goal is to make a language as simple a possible
and given that they do not add functionality, enumeration types are not required.
- no subranges, which are no longer needed for array index range declarations, because
array bounds generally start at 0
- no enumerations
- no unsigned type (CARDINAL)
- no nested modules, which did not add any functionality
- no variant records, which are replaced by the safer concept of extensible records
- no WITH-statement of the Modula-2 language, which had many disadvantages in respect
to program readability and thus severed maintainability
- no qualified import, i.e. imported identifiers must be qualified with the module name or its alias
- no separate definition- and implementation-module
Oberon-2 main features
Persistent objects and meta-programming facilities
are supported via a library module.
- integer type hierarchy
- objects, called extensible records
- polymorphic types and single inheritance; methods are simply type bound procedures
- type test and type guard
- dynamic arrays, allocated on the heap, where the array index range can be determined at run-time
- read-only export
- import module name alias
As an advantage over Modula-2, Oberon-2 features save pointers
under the provision that SYSTEM.ADR and type casting SYSTEM.VAL is not used.
All pointer variables, even when declared within a structured type,
be it global, local, or heap are inititialised to NIL and there
is no DISPOSE (although stand-alone implementation without garbage collector
might allow to use Objects.DISPOSE).
Run-time check of a pointer type is done via so-called type descriptors
and pointer type tags for both, static and dynamic objects.
Oberon-2 is simpler, but more powerful than Modula-2.
Object Oriented Programming in Oberon-2
by H.P. Mössenböck, Springer Verlag, 1993;
available in English and in German.
The Alignment Trap :: Navigator
[ The Alignment Trap Home |
About The Alignment Trap |
Oberon System and Compiler Implementations (OSCI) |
Comparison of Oberon-2 with Modula-2 |
From C/C++ to Oberon-2 |
Oberon-2 Language Report |
AlphaOberon-2 Compiler User's Guide |
Download AlphaOberon for OpenVMS Alpha ]
Copyright (c) (1999-2011) by modulAware.com
Last revised 01-Mar-2011
Disclaimer: The banner advertisement
at the top of this page is dynamically inserted by the web-site hosting service;
The banner image content and the URL it refers to is outside the responsibility of modulAware.com