[TABLE OF CONTENTS] [BOTTOM] - [NEXT]

Author:  Rony G. Flatscher

For:     ANSI NCITS J18

Purpose: Tiling of Classes, Method Resolution

Version: 0.9.1

History: 0.9.1: replaced HTML-reports with correct tiling,

                added link to retrieve ANSI_UPD.ZIP

As of:   1997-08-26

Status:  DRAFT

Please send comments to Rony.Flatscher@wu-wien.ac.at

Abstract

This paper briefly discusses the 'tiling' of class objects which is fundamental to Object Rexx because method resolution is structurally bound to this tiling.

[Hint: all files together are 1,1 MB in total size, mostly due to the HTML-reports. You may want to retrieve the ZIP-archive (rgf_tiling.zip, size: 176KB) and view this document offline.]

[TOP] [BOTTOM] - [PREVIOUS] [NEXT] Table of Contents


        1   'Tiling' of Classes


        2   Example Programs and the 'Tiling' of Classes


        2.1 Example: Tiling of Classes, Simple Case


        2.2 Example: Tiling of Classes, Simple Case Enhanced with Metaclasses


        2.3 Example: Tiling of Classes, Complex Case

[TOP] [TABLE OF CONTENTS] [BOTTOM] - [PREVIOUS] [NEXT]

1 'Tiling' of Classes

Whenever a class subclasses another one all of the class and instance methods of the subclassed class are inherited. This inheritance takes place for every superclass up to and including the root class "Object" of the Object Rexx class tree. Putting the class objects on top of each other according to the inheritance order is called tiling of classes.
Object Rexx allows for multiple inheritance. In the case that multiple classes are defined such, that there exists an (in)direct inheritance among them, the tiling may change the effective superclass order, to avoid searching the same superclass more than once!
This may be the case, if e.g. class x_subclass is a subclass of y_superclass and the user defined ordering of the inherited superclasses uses the order "y_superclass x_subclass" instead of "x_subclass y_superclass".
A class object which represents a class definition can be pictured as consisting of two disjoint columns, one for the class scope (class methods and class variables) and one for the instance scope (instance methods and instance variables). Ultimately, every class object inherits from the root class object.
Every class object is itself an instance of a metaclass, usually of the Object Rexx default metaclass class. [In OOI there are additional metaclasses for the SOM and DSOM support.]
Instance methods of metaclasses are accessible via inheritance at the class level scope by the class object. With other words, if metaclasses are tiled, they need to be tiled such that they shift horizontally to place the metaclass' instance scope right above the class object's class scope. This way the metaclass instance methods become accessible as class methods.
Class methods of metaclasses are out of scope for class objects. In order to gain access to class methods of metaclasses the metaclass' class object has to be retrieved by sending the METACLASS message to the original class object.
As a metaclass is itself a normal Object Rexx class it can be subclassed to build new, specialized metaclasses. Orthogonality mandates also, that a metaclass may be constructed using a specific metaclass too! [Of course, in such a case a horizontal shift has to occur while tiling the class objects. Of course, the tiling for a metaclass will finally lead into the Object Rexx root class Object also.]

[TOP] [TABLE OF CONTENTS] [BOTTOM] - [PREVIOUS] [NEXT]

2 Example Programs and the 'Tiling' of Classes

What follows are three different (program generated) Object Rexx programs, which were first produced, then run with their output collected. In addition they were processed by "ORX_ANALYZE_HTML.CMD" (cf. ORX7.ZIP, documentation in: ORX7DOC.ZIP; ORX7.ZIP needs the utility programs of ORX8.ZIP, documentation in: ORX8DOC.ZIP; for ANSI-purposes please apply the enclosed fixpack ANSI_UPD.ZIP which corrects the tiling algorithm used in the ORX7.ZIP programs) yielding HTML-files showing the inferred tiling of the classes (as described here) in the detailed views.

Each subsection will contain an excerpt of the class definitions, and links to the generator program, the generated Object Rexx program, the output if that generated program is run, and the results of analyzing the generated Object Rexx programs by ORX_ANALYZE_HTML.CMD.

Every class will have two methods (INIT, RGF) defined for the instance and the class scope. Every method will display in which class object it is executing and invoke the superclass' method by the same name at the appropriate scope. The methods in the class definitions which have object as their direct superclass are the only ones which do not forward the message to super.

The three generated programs are:

"SIMPLE.CMD": A program containing a simple inheritance tree.
"SIMPLE+META.cmd": "SIMPLE.CMD" extended by some metaclasses, where two metaclasses use explicitly metaclasses for their own class objects.
"COMPL.CMD": The same metaclass definitions as in "SIMPLE+META.cmd" plus an elaborate set of object classes with simple/multiple inheritance and using various metaclasses for themselves.

[Please note, that these three programs were just created to demonstrate the tiling of classes and do not achieve anything meaningful besides it.]

There are real-world cases where especially the feature that metaclasses can be created by using metaclasses themselves, becomes very important, e.g. in representing modelling, meta-modelling and meta-meta-modelling semantics in Object Rexx programs.

[TOP] [TABLE OF CONTENTS] [BOTTOM] - [PREVIOUS] [NEXT]

2.1 Example: Tiling of Classes, Simple Case

A program containing a simple inheritance tree. Here are the extracted class definitions:

:: CLASS B_Object_Class  MIXINCLASS Object

   :: METHOD INIT CLASS /* class scope          */
   :: METHOD RGF CLASS

   :: METHOD INIT       /* instance scope       */
   :: METHOD RGF


:: CLASS C1_Object_Class MIXINCLASS B_Object_Class

   :: METHOD INIT CLASS /* class scope          */
   :: METHOD RGF CLASS

   :: METHOD INIT       /* instance scope       */
   :: METHOD RGF

The generator program: simple/simple-gen.cmd
The program itself: simple/simple.cmd
The output: simple/simple.out
The HTML formatted results of analyzing the program and inferring the tiling (use the detailed links for navigating to the detailed tiling of classes): simple/HTML_Summary.html

[TOP] [TABLE OF CONTENTS] [BOTTOM] - [PREVIOUS] [NEXT]

2.2 Example: Tiling of Classes, Simple Case Enhanced with Metaclasses

"SIMPLE.CMD" extended by some metaclasses, where two metaclasses use explicitly metaclasses for their own class objects. Here are the extracted class definitions (method definitions the same as in the simple case, therefore omitted):

:: CLASS Meta_Class          SUBCLASS   class

:: CLASS Meta_Class_Sub1     SUBCLASS   Meta_Class

:: CLASS Meta_Class_Sub2     SUBCLASS   Meta_Class

:: CLASS Meta_Class_Sub1_1   SUBCLASS   Meta_Class_Sub1     METACLASS Meta_Class_Sub2

:: CLASS Meta_Class_Sub1_1_1 SUBCLASS   Meta_Class_Sub1_1

:: CLASS Meta_Class_Sub3     SUBCLASS   Meta_Class


:: CLASS B_Object_Class      MIXINCLASS Object              METACLASS Meta_Class_Sub1

:: CLASS C1_Object_Class     MIXINCLASS B_Object_Class      METACLASS Meta_Class_Sub3

The generator program: simple+meta/simple+meta-gen.cmd
The program itself: simple+meta/simple+meta.cmd
The output: simple+meta/simple+meta.out
The HTML formatted results of analyzing the program and inferring the tiling (use the detailed links for navigating to the detailed tiling of classes) (method definitions the same as in the simple case, therefore omitted): simple+meta/HTML_Summary.html

[TOP] [TABLE OF CONTENTS] [BOTTOM] - [PREVIOUS] [NEXT]

2.3 Example: Tiling of Classes, Complex Case

The same metaclass definitions as in "SIMPLE+META.cmd" plus an elaborate set of object classes with simple/multiple inheritance and using various metaclasses for themselves. Here are the extracted class definitions:

:: CLASS Meta_Class          SUBCLASS   class

:: CLASS Meta_Class_Sub1     SUBCLASS   Meta_Class

:: CLASS Meta_Class_Sub2     SUBCLASS   Meta_Class

:: CLASS Meta_Class_Sub1_1   SUBCLASS   Meta_Class_Sub1     METACLASS Meta_Class_Sub2

:: CLASS Meta_Class_Sub1_1_1 SUBCLASS   Meta_Class_Sub1_1

:: CLASS Meta_Class_Sub3     SUBCLASS   Meta_Class


:: CLASS A_Object_Class      SUBCLASS   object              METACLASS Meta_Class

:: CLASS B_Object_Class      MIXINCLASS Object              METACLASS Meta_Class_Sub1

:: CLASS C1_Object_Class     MIXINCLASS B_Object_Class      METACLASS Meta_Class_Sub3

:: CLASS C1_1_Object_Class   MIXINCLASS B_Object_Class      METACLASS Meta_Class_Sub1_1

:: CLASS D_Object_Class      MIXINCLASS A_Object_Class      METACLASS Meta_Class_Sub2

:: CLASS E_Object_Class      SUBCLASS   B_Object_Class      METACLASS Meta_Class_Sub1_1   INHERIT C1_Object_Class C1_1_Object_Class

:: CLASS F_Object_Class      SUBCLASS   A_Object_Class      METACLASS Meta_Class_Sub2     INHERIT D_Object_Class

:: CLASS G_Object_Class      SUBCLASS   B_Object_Class      METACLASS Meta_Class_Sub1     INHERIT C1_Object_Class C1_1_Object_Class

:: CLASS H_Object_Class      SUBCLASS   B_Object_Class      METACLASS Meta_Class          INHERIT C1_Object_Class C1_1_Object_Class

:: CLASS I_Object_Class      SUBCLASS   H_Object_Class

Hint: try to determine the tiling of class E_Object_Class (solution in the detailed HTML-report below).

The generator program: compl/compl-gen.cmd
The program itself: compl/compl.cmd
The output: compl/compl.out
The HTML formatted results of analyzing the program and inferring the tiling (use the detailed links for navigating to the detailed tiling of classes): compl/HTML_Summary.html

Please send comments to Rony.Flatscher@wu-wien.ac.at

[TOP] [TABLE OF CONTENTS] - [PREVIOUS]