1 / 64

DEV-20: Using Classes and Procedures in OpenEdge 10.1B

DEV-20: Using Classes and Procedures in OpenEdge 10.1B. Goals of this Session. Classes and procedures are not so differentHowever there are key distinctions and benefitsClasses and procedures can work togetherYou can keep all of your existing proceduresAnd start developing using classes today. W

yvon
Download Presentation

DEV-20: Using Classes and Procedures in OpenEdge 10.1B

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. DEV-20: Using Classes and Procedures in OpenEdge® 10.1B Introducing Object-Oriented code into your Application

    2. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Goals of this Session Classes and procedures are not so different However there are key distinctions and benefits Classes and procedures can work together You can keep all of your existing procedures And start developing using classes today

    3. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Agenda Classes & Procedures Strong Typing Data Members, Properties & Methods Constructors & Destructors Instantiation & Destruction Mixing Procedures and Classes Together Error Handling Global Variables

    4. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Classes & Procedures

    5. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Class & Procedure Definitions .p file extension No code necessary Weak type Late-binding at run-time -p startup parameter Directly accessible across AppServer boundary

    6. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Strong Typing Class as a data type Class type references checked at compile-time Also includes checking of: Data members Properties Methods Eliminates type errors at run-time which are common using procedures

    7. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Strong Typing

    8. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Runtime Type Checking

    9. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Compile-Time Type Checking

    10. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Data Members ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships. ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships.

    11. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Data Members ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships. ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships.

    12. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Data Members Variables, buffers, streams, GUI objects, buffers, queries, temp-tables, ProDataSets, data sources, work tables Access Modifiers PRIVATE (Default for Data Members) PROTECTED PUBLIC Temp-Tables & ProDataSets must be defined at Class level (similar to procedures) ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships. ABL supports data members in classes in a similar way to the data elements that you define in the main block of a persistent procedure. However, data elements in a procedure are always private, unless they are specified as SHARED, in which case they can be shared among different external procedures (persistent or non-persistent). ABL does not allow shared variables to be directly accessed by classes. The variables and other data elements defined in the main block of an external procedure are private without having an explicit access mode. That is, they are scoped to the procedure, including its internal procedures and user-defined functions, but cannot be accessed directly from other external procedures. In the same way, data members defined in a class with no access mode are PRIVATE and accessible from all methods defined in the class, but they cannot be accessed directly from other classes, whether inside or outside of the class hierarchy. USING acme.myObjs.*. CLASS acme.myObjs.NECustObj INHERITS CustObj: METHOD PRIVATE VOID DisplayCust ( ): iNumCusts = iNumCusts + 1. FOR EACH ttCust: DISPLAY ttCust. END. END METHOD. END CLASS. USING acme.myObjs.*. CLASS MyMain: DEFINE PRIVATE VARIABLE rNECust AS CLASS NECustObj NO-UNDO. METHOD PRIVATE VOID DisplayCust ( ): rNECust = NEW NECustObj( ). rNECust:iNumCusts = rNECust:iNumCusts + 1. /* Can not access PROTECTED ttCust */ DELETE OBJECT rNECust. rNECust = ?. END METHOD. END CLASS. Using the CLASS construct 2–19 Procedures can define SHARED variables, which are scoped to and accessible from other external procedures. The variable definitions must be defined as NEW SHARED in a parent procedure and the definitions repeated as SHARED in each called external procedure that needs to access them. This is necessary because the compiler does not look at other external procedures when compiling a procedure. Classes do not support SHARED variables, which must be defined both for where they are stored and for where they are referenced. PROTECTED and PUBLIC data members in classes provide wider access to class data members and without the need to repeat the data member definitions. However, they must be referenced with respect to the instantiated object where they are defined. So, PROTECTED data members can only be referenced within the same class hierarchy of a single instantiated object where they are defined; and PUBLIC data members can be referenced like PROTECTED data members, within the class hierarchy, and also from outside the class hierarchy. However, PUBLIC data members can only be referenced outside the class hierarchy where they are defined by using an object reference to the instantiated class that defines them. These referential restrictions both conform to class and object relationships and allow the compiler to validate data member references for consistency based on these relationships.

    13. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Properties Persistent procedures have no direct equivalent to properties of a class. You can simulate the function of properties in a persistent procedure by defining user-defined functions, each of which encapsulates access to a corresponding variable defined in the main block. In procedures, the closest equivalent to a property is a user-defined function. You might define one function equivalent to the GET accessor that returns a value, and another function (or internal procedure) equivalent to the SET accessor that accepts the setting value as an INPUT parameter. Persistent procedures have no direct equivalent to properties of a class. You can simulate the function of properties in a persistent procedure by defining user-defined functions, each of which encapsulates access to a corresponding variable defined in the main block. In procedures, the closest equivalent to a property is a user-defined function. You might define one function equivalent to the GET accessor that returns a value, and another function (or internal procedure) equivalent to the SET accessor that accepts the setting value as an INPUT parameter.

    14. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Properties Persistent procedures have no direct equivalent to properties of a class. You can simulate the function of properties in a persistent procedure by defining user-defined functions, each of which encapsulates access to a corresponding variable defined in the main block. In procedures, the closest equivalent to a property is a user-defined function. You might define one function equivalent to the GET accessor that returns a value, and another function (or internal procedure) equivalent to the SET accessor that accepts the setting value as an INPUT parameter. Persistent procedures have no direct equivalent to properties of a class. You can simulate the function of properties in a persistent procedure by defining user-defined functions, each of which encapsulates access to a corresponding variable defined in the main block. In procedures, the closest equivalent to a property is a user-defined function. You might define one function equivalent to the GET accessor that returns a value, and another function (or internal procedure) equivalent to the SET accessor that accepts the setting value as an INPUT parameter.

    15. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Methods Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle. Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle.

    16. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Methods Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle. Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle.

    17. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Methods Methods combine characteristics of internal procedures and user-defined functions Access Modifiers PRIVATE PROTECTED PUBLIC (Default for Members) Methods can raise ERROR condition Methods with a return type cannot block for input Methods can be overloaded Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle. Methods generally combine the characteristics of internal procedures and user-defined functions, and add features unique to classes. Also, unlike user-defined functions, methods can raise the ERROR condition. You cannot use any statements or ABL elements in the method-body that are only relevant in procedures, such as a reference to the THIS-PROCEDURE system handle.

    18. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Constructors For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor. For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor.

    19. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Constructors For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor. For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor.

    20. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Constructors Constructor equates to Main Block in procedure Constructor parameters equates to procedure parameters Constructor name must be same as Class Cannot have a return type If not explicitly defined, default constructor with no parameters is provided. Constructors can be overloaded For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor. For persistent procedures, the equivalent behavior executes directly in the main block, and there are no restrictions on where and when a particular persistent procedure can be instantiated. A constructor for a class is similar to the main block of a persistent procedure. Parameters passed to a class's constructor are similar to parameters passed to a persistent procedure when it is run. When you instantiate a class using the NEW phrase, the specified constructor executes as part of the class constructor hierarchy and returns to the caller assigning the object reference to the instantiated class. The caller can then use this object reference to access public data members and properties and to call public methods on this class-based object. When a procedure is first run PERSISTENT, the code in its main block executes and returns to the caller, setting the procedure object handle. The caller can then access any variables that it shares globally with the procedure object and can use the procedure object handle to run internal procedures and user-defined functions in the procedure object. The syntax for the SUPER statement appears similar to the syntax for the SUPER built-in function, used to invoke user-defined functions in a super procedure. However, unlike the SUPER built-in function, which you must invoke inside an expression in a procedure, you can only invoke the SUPER statement as the first statement in a subclass constructor.

    21. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Constructors Access Modifiers PRIVATE PROTECTED PUBLIC (Default for constructors) PRIVATE constructors can only be invoked by another constructor defined in the Class PROTECTED constructors can only be invoked by another constructor defined in the Class or a subclass

    22. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Destructors Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies. Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies.

    23. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Destructors Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies. Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies.

    24. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Destructors Uniform mechanism to handle cleanup tasks No real equivalent in procedures Analogous to ON CLOSE OF THIS PROCEDURE Caution: Not automatically run when client session ends Runs on explicit deletion on DELETE OBJECT Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies. Persistent procedures have no equivalent for a destructor. With persistent procedures, the application must adhere to an enforced programming strategy in order to allow cleanup when the procedure exits. Typically, you do this by defining a trigger block to be executed ON CLOSE OF THIS-PROCEDURE, then take care to always delete a persistent procedure instance using the APPLY "CLOSE" statement rather than using the DELETE OBJECT statement. (This is the convention used in procedures generated by the AppBuilder.) A destructor provides a uniform mechanism to handle such cleanup tasks in class-based objects without the need for special programming strategies.

    25. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Instantiation Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    26. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Instantiation Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    27. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Instantiation NEW statement analogous to RUN proc PERSISTENT SET handle VALID-OBJECT function analogous to VALID-HANDLE Class instance reference has a type TYPE-OF function Persistent procedure handle has no type Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    28. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Invoking Methods When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked. When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked.

    29. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Invoking Methods When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked. When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked.

    30. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Invoking Methods When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked. When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked.

    31. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Invoking Methods When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked. When you invoke an internal procedure from within an external procedure where it is defined, you use a RUN statement that simply names the procedure. When you invoke a user-defined function within an external procedure where it is defined, you name the function in an expression, similar to invoking a method within a class. However, you have to forward reference the definition for the user-defined function if it occurs after the point of invocation. When you invoke an internal procedure defined in another external procedure, you use the RUN statement with an IN option to specify the location of the internal procedure definition. When you invoke a user-defined function defined in another external procedure, you must specify the prototype and reference the location of the function definition, then invoke the function by naming it in an expression. Method invocation within its defining class or on an another object instance is far more consistent than for internal procedures and user-defined functions. Methods never require a separately declared prototype in the class where they are invoked, as user-defined functions sometimes do in the procedure or class where they are invoked.

    32. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Destruction Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    33. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Destruction Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    34. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Inheritance Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    35. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Inheritance Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    36. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Constructor Overloading Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    37. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Method Overloading Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    38. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Inheritance Data Member & Property scoping within a Class Hierarchy (Protected) Method scoping within a Class Hierarchy Method Overriding Method & Constructor Overloading Procedures do not support Interfaces, Method Overloading, or Constructor Overloading.

    39. DEV-20: Using Classes and Procedures in OpenEdge 10.1B THIS-PROCEDURE vs. THIS-OBJECT Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    40. DEV-20: Using Classes and Procedures in OpenEdge 10.1B THIS-PROCEDURE vs. THIS-OBJECT

    41. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Procedure & Class Interoperability Object references and a procedure handles represent two very different constructs Cannot execute r-code for a class using the RUN statement. Must use the NEW phrase. Cannot use the NEW phrase to run a persistent procedure. An instance of a class never has a procedure object handle associated with it. So there is no THIS-PROCEDURE or TARGET-PROCEDURE or SOURCE-PROCEDURE handles A procedure has no notion of a class or object reference. So there is no THIS-OBJECT reference Cannot assign a procedure handle to an object reference. Cannot assign an object reference to a procedure handle. Cannot cast a procedure handle to an object reference or an object reference to a procedure handle.

    42. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Procedure & Class Interoperability Cannot pass an object reference to a routine expecting a procedure handle. Cannot pass a procedure handle to a routine expecting an object reference. Cannot define methods in a procedure, only in classes Cannot define internal procedure or user-defined functions in classes, only in external procedures. Cannot use the object-reference:method-name syntax to run an internal procedure or a function, but only a method. But can use this syntax in both classes and procedures. Cannot define a constructor or destructor for a procedure, only in classes. Cannot specify a PUBLIC, PRIVATE, or PROTECTED access mode on a class member except in the main block of a class.

    43. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Procedure & Class Interoperability Cannot use ADD-SUPER-PROCEDURE( ) method on the THIS-OBJECT or THIS-PROCEDURE handle within a class. Cannot add a class-based object as a super procedure. But within a class, can use the SESSION:ADD-SUPER-PROCEDURE( ) method to extend the super procedure chain of the SESSION handle. And can use the procedure-handle:ADD-SUPER-PROCEDURE( ) method, where procedure-handle is a procedure object handle set from running a persistent procedure, in order to extend the super procedure chain for other, procedure objects.

    44. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Using a Class in a Procedure

    45. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Using a Procedure in a Class

    46. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Error Handling Other OO languages have try… catch… We will have something like it too RETURN ERROR, NO-ERROR, ON-ERROR and ERROR-STATUS all continue to work with Classes

    47. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Error Handling in Procedures & Methods Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    48. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Error Handling in Procedures & Methods Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference Using theAssignment (=)statement with the NEW phrase to instantiate a class and assign its object reference is roughly equivalent to running a persistent procedure and setting its procedure object handle using the RUN statement. Just as a procedure-based ABL application that instantiates persistent procedures must begin with a startup procedure file that directly or indirectly (through other procedure files) creates procedure objects, a class-based ABL application must also begin with a startup procedure file that directly or indirectly creates class-based objects. (You cannot directly startup an application with ABL using a class file as you can, for example, with Java.) When it is no longer needed, you can use the DELETE OBJECT statement to destroy either a persistent procedure or an instance of a class VALID-OBJECT function THIS-OBJECT Statement THIS-OBJECT reference

    49. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Global Variables Other OO languages have STATIC We will too – in the future Need access to existing global variables Cannot be accessed in directly within classes OO-Procedural interoperability helps

    50. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Global Variables Example – Procedural Side

    51. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Global Variables Example – OO Side

    52. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Include Files

    53. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Include Files

    54. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Preprocessor Names & Directives All preprocessor directives, such as &IF, &GLOBAL-DEFINE, and &SCOPED-DEFINE, can be used in classes and behave as they do in procedures. All built-in preprocessor names are supported in classes including BATCH-MODE, FILE-NAME, LINE-NUMBER, OPSYS, SEQUENCE and WINDOW-SYSTEM.

    55. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Preprocessor Names & Directives

    56. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Preprocessor Names & Directives

    57. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Defining Widgets & Handling Events

    58. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Handling Events – ON statement

    59. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Some Additional Items for You to Research SET-CALLBACK() using Class methods Using WIDGET POOLS SESSION:FIRST-OBJECT, LAST-OBJECT Packages vs. Propath directories Compiler Options

    60. DEV-20: Using Classes and Procedures in OpenEdge 10.1B In Summary Classes and procedures are not so different However there are key distinctions and benefits Classes and procedures can work together very well You can keep all of your existing procedures And start developing using classes today

    61. DEV-20: Using Classes and Procedures in OpenEdge 10.1B For More Information, go to… PSDN Implementing the OpenEdge Reference Architecture with Classes http://www.psdn.com/library/kbcategory.jspa?categoryID=1212 Progress eLearning Community What's New OE 10.1 Object Oriented Programming Documentation 10.1B Object-oriented Programming manual 10.1B New and Revised Features manual

    62. DEV-20: Using Classes and Procedures in OpenEdge 10.1B Relevant Exchange Sessions DEV-6: Getting Started with Object-Oriented Programming DEV-12: Object-Oriented Programming in OpenEdge ABL ARCH-7: A Class-Based Implementation of the OERA ARCH-12: Leveraging Design Patterns in ABL Applications

    63. DEV-20: Using Classes and Procedures in OpenEdge 10.1B

    64. DEV-20: Using Classes and Procedures in OpenEdge 10.1B

    65. DEV-20: Using Classes and Procedures in OpenEdge 10.1B

More Related