1104 EMULATING OBJECT TECHNOLOGY IN NON-O-O ENVIRONMENTS $34.3 The multiple-entry subroutine technique The COMMON-based technique,as you will have noted,violates the Linguistic Modular Units principle.In a system's modular structure,the routines are physically independent although conceptually related.You can all too easily update one and forget the others. It is in fact possible to improve on this situation (without removing some of the other limitations just listed)through a language trait legalized by Fortran 77:multiple entry points to a single routine. This extension-which was probably introduced for different purposes,but may be redeemed for the"good cause"-enables Fortran routines to have entry points other than the normal routine header.Client routines may call these entry points as if they were autonomous routines,and the various entries may indeed have different arguments. Calling an entry will start execution ofthe routine at the entry point.All entries ofa routine share the persistent data of the routine;a persistent data item,which in Fortran 77 must appear in a SAlE directive,is one whose value is retained from one activation of a routine to the next.Well,you see where we are driving:we can use this technique to define a module that encapsulates an abstract object,almost as we would in one of the encapsulation languages.In Ada,for example,we could write a package with a data structure declaration,such as a stack representation,and a set of routines that manipulate these data.Here we will simulate the package with a subroutine,the data structure with a set of declarations that we make persistent through a S4VE,and each Ada routine (each feature of the corresponding class in an O-O language)with an entry.Each such entry must be followed by the corresponding instructions and a RETURN: ENTRY (arguments) ...Instructions... RETURN so that the various entry-delimited blocks are disjoint:control never flows from one block to the next.This is a restricted use of entry points,which in general are meant to allow entering a routine at any point and then continuing in sequence.Also note that clients will never call the enclosing subroutine under its own name;they will only call the entries. The main difference with the preceding CoMMON-based solution is that all the features of the underlying abstract data type now appear in the same syntactical unit.The second part of the facing page shows an example implementing an abstract object(stack of reals).The calls from a client will look like this: LOGICAL OK REAL X OK=MAKE( OK=PUT(4.5) OK=PUT(-7.88) X=ITEM() OK=REMOVE IF (EMPTY (A=B1104 EMULATING OBJECT TECHNOLOGY IN NON-O-O ENVIRONMENTS §34.3 The multiple-entry subroutine technique The COMMON-based technique, as you will have noted, violates the Linguistic Modular Units principle. In a system’s modular structure, the routines are physically independent although conceptually related. You can all too easily update one and forget the others. It is in fact possible to improve on this situation (without removing some of the other limitations just listed) through a language trait legalized by Fortran 77: multiple entry points to a single routine. This extension — which was probably introduced for different purposes, but may be redeemed for the “good cause” — enables Fortran routines to have entry points other than the normal routine header. Client routines may call these entry points as if they were autonomous routines, and the various entries may indeed have different arguments. Calling an entry will start execution of the routine at the entry point. All entries of a routine share the persistent data of the routine; a persistent data item, which in Fortran 77 must appear in a SAVE directive, is one whose value is retained from one activation of a routine to the next. Well, you see where we are driving: we can use this technique to define a module that encapsulates an abstract object, almost as we would in one of the encapsulation languages. In Ada, for example, we could write a package with a data structure declaration, such as a stack representation, and a set of routines that manipulate these data. Here we will simulate the package with a subroutine, the data structure with a set of declarations that we make persistent through a SAVE, and each Ada routine (each feature of the corresponding class in an O-O language) with an entry. Each such entry must be followed by the corresponding instructions and a RETURN: ENTRY (arguments) … Instructions … RETURN so that the various entry-delimited blocks are disjoint: control never flows from one block to the next. This is a restricted use of entry points, which in general are meant to allow entering a routine at any point and then continuing in sequence. Also note that clients will never call the enclosing subroutine under its own name; they will only call the entries. The main difference with the preceding COMMON-based solution is that all the features of the underlying abstract data type now appear in the same syntactical unit. The second part of the facing page shows an example implementing an abstract object (stack of reals). The calls from a client will look like this: LOGICAL OK REAL X C OK = MAKE () OK = PUT (4.5) OK = PUT (–7.88) X = ITEM () OK = REMOVE () IF (EMPTY ()) A = B