VIRTUAL METHODS in OBJECT-ORIENTED PROGRAMMING.
             ßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßßß

 In the introduction OOPINTRO.TXT, it was observed that inherited methods
 are sometimes not appropriate to the descendant object. For example,
 a circle could not inherit the method Point.Show, even though the data
 fields and some methods could be correctly inherited from a point.
 Normally when code is compiled, the addresses of any methods are resolved
 at that time, but where methods like 'Show' have the same name for a
 descendant object but need to be different, the decision as to which
 method is appropriate must be delayed until run-time.

 Giving a method one name that is shared up and down the object hierarchy,
 with each object in the hierarchy implementing the action in a way
 appropriate to itself is called 'Polymorphism'.  It is achieved by using
 'Virtual Methods', as illustrated in the program RIGHTOOP.PAS where the
 procedures script1 and script2 are declared as virtual by the addition of
 'virtual;' as shown:
                      procedure script1;  virtual;
                      procedure script2;  virtual;

 When methods are 'static' (as opposed to virtual) references to the
 procedure or function addresses must be resolved at compile time, so that
 the code can be properly processed.  This is called 'early binding'.
 By comparison, when a method is declared 'virtual', it is compiled in such
 a way that identification of which method to use is delayed until the
 program is run.  This is 'late binding' and involves a table of the
 addresses of the various methods, as mentioned in the next paragraph and
 described in the note VMT.TXT

 Two syntactic changes must be made in order to use virtual methods.
 First, every instance of an object type must be initialized using a
 special procedure called a 'Constructor'.  The special effect of using a
 constructor is the creation of a 16-bit field, called a Virtual Method
 Table (VMT) field, in the object type.  Thus instead of a Procedure Init,
 as used for objects without virtual methods, Constructor Init is employed
 as shown:
            constructor Init(SurName : string );

 The second change is the inclusion of the keyword 'virtual' at the end of
 the line that declares a virtual method.  Thus in the program RIGHTOOP.PAS
 the procedures script1 and script2 are declared virtual for both the staff
 object and the junior object.  Thus when the procedure xxxxx.action1 calls
 the procedure script1 the appropriate script1 is called. Similarly the
 procedure xxxxx.action2 calls the appropriate script2.
       [xxxxx represents either staff or junior]

 Although using virtual methods slows the program and uses memory, it is
 generally recommended as it allows for 'extensibility' - the use of compiled
 code in the form of a unit (.TPU) without having the source code available.
 This technique is illustrated in the program JUNIOROB.PAS which uses a unit
 called 'staffobj', created from the program STAFFOBJ.PAS  It performs
 the same actions as the program RIGHTOOP.PAS mentioned above.

 The program JUNIOROB.PAS contains the appropriate 'uses' clause:

          uses Crt, staffobj;

 whilst the unit staffobj contains the relevant interface and implementation
 sections.


 See separate note entitled 'Virtual Methods and the Virtual Method Table',
 (VMT.TXT) for further details.

 VIRTUAL.TXT
 Revised 31.5.93