Download
1 / 64
650 likes | 1.31k Views
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
E N D
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
