Minor Classes for NetRexx
The Java language specification for Java 1.1 was enlarged with a
specification known as Inner Classes. That specification
describes ways by which classes can appear to be 'inside' other classes,
hence providing simplified access to their properties while reducing the
number of primary class names in a package.
In the Java language, two distinct forms of inner classes are provided:
those which are visible outside the containing class (sometimes called
nested and member classes), and those which are not
(local and anonymous classes). The primary benefits of
the local and anonymous inner classes are already available in NetRexx
1.1 as adapter classes, but means of accessing and creating
externally visible inner classes are not. Since these can be exposed in
published specifications, languages that are to take full advantage of
the Java environment must support access to these classes (and, by
implication, allow their definition).
The design for support of these externally visible classes in NetRexx
takes a fresh view of inner classes.
Specifically, nested classes primarily offer a naming (packaging)
convention, with little effect on scope. In addition, the rules added
for member classes are similar to those that relate a subclass to its
superclass; indeed, in some ways, member classes offer an alternative
(though less flexible) inheritance hierarchy.
Seen in this light, inner classes of both types are no more 'inside'
their parent class than a subclass is 'inside' its superclass.
The design for NetRexx therefore presents them both as minor
classes, with syntax and access mechanisms that parallel those
already existing in NetRexx.
The rules for member classes are supported by the concept of a
dependent class - a minor class which has privileged access to
the its parent object and its properties.
The full description of minor and dependent classes may be found in
This is also available in
(Acrobat) format for viewing or printing.
Many people have contributed to the discussions that led to this design.
I would especially like to thank Dion Gillard, Martin Lafaix, and Rick
McGuire for their detailed comments and suggestions.