1. Object-oriented programming in the Progress® 4GL 10.1A Beta
Salvador Viñals
Consultant Product Manager
OpenEdge 10.1A1B Beta

2. Agenda Introduction and goals of OO in the 4GL Concepts and overview
An example
Tools support for OO in the 4GL
Beta use cases

3. Object-oriented Application Development
A way to design and build applications
Objects bundle together data (state) and methods (behavior)
Objects facilitate separating definition from implementation
Much more than just syntax
You might have already done object-oriented programming in the 4GL

4. Object-orientation and the 4GL
Goals
Extend the 4GL to support the OO programming model
Retain existing strengths
A natural basis for OpenEdge Reference Architecture applications
Programming with classes
More closely support SOA
Multiple rollouts
10.1A first one
There are standard concepts that all object-oriented programming languages support. Within the 4GL, pre 10.1A, there is limited support for object-oriented techniques with persistent procedures. Variables, buffers, temp-tables etc. defined in the main block of a persistent procedure are the data (members) while internal procedures and UDFs are the methods.
The goal of the object-oriented language initiative is to extend the language to provide a cohesive and standard object-oriented programming model within the Progress 4GL while continuing to support the current programming model. This object-oriented language support in the 4GL is a natural basis for writing applications that conform to the OpenEdge Reference Architecture (OERA) introduced for OpenEdge Release 10.
These language enhancements introduce a complete set of object-oriented constructs which provide all the standard behavior for programming with classes expected within the object-oriented community. Anyone with an object-oriented background should feel very comfortable programming with classes in OpenEdge.
There are many design and modeling tools that work with object-oriented concepts, which could be used to design objects and then translate the object model to the 4GL using the new support for classes.
Support for classes is designed to enhance the power of the 4GL while retaining the core value of the 4GL in terms of business orientation, high productivity, and ease of use. These features are the true power of the 4GL that differentiate it from other development languages.
Service oriented architectures (SOA) are typically object based, so the OO4GL more closely matches and supports such implementations.

5. OO in the 4GL Features CLASS definitions
Single inheritance hierarchies
Data members and methods
Interfaces
The new syntax introduces a number of new constructs within the language. First is the new CLASS construct which is used to define new user-defined types in the 4GL. The classes defined by the CLASS construct contain both data and methods. Class definitions support single inheritance of other classes. Classes may implement one or more interfaces.
The CLASS statement identifies the source code file as representing a class and not a traditional Progress procedure. Within a class, there are several new language statements that are distinctive to classes and which can be used only within them. You can use the vast majority of the 4GL syntax within classes, and for the most part in exactly the same way as in Progress procedures. So now there are 2 ways to think about the introduction of classes into the Progress 4GL. On the one hand, there is a clear and absolute distinction between classes and procedures, and the compiler can tell from the very first statement in a source file which it is dealing with; on the other hand, the majority of the programming that you do within a class can be very much the same as within a procedure, which means that programming with classes can very quickly become familiar and natural to you and to other existing OpenEdge developers.

6. Benefits of OO in the 4GL Programming Business Encapsulation
Maintenance
Inheritance
Promotes reuse
Code reuse
Productivity
Interfaces
Contracts
Strong typing
Robustness
Invocation model
Ease of use
Maps modeling tools
Efficient dev cycle
.cls - .p interoperability
Not disruptive
Supports a powerful programming model by encapsulating related functionality and data into objects. The benefit of organized code is especially important for maintenance where changes or enhancements can be limited to the objects that are affected by the change.
Enhances code reuse. Common code can be put into a super-class and shared among other related classes. The sub-classes can provide specialized behavior whenever necessary to extend the super functionality.
Methods and data are invoked in the same way, through the use of object references, providing a more consistent approach than possible before.
The strong-typing provided by classes enables Progress to do compile-time checking to catch errors before the code is run or deployed and checks all code paths not just the ones that are executed during testing.
It maps much more closely to the constructs used by modeling tools and other design tools that are used more and more to provide a basis for application design and even code generation.
Promotes modular design
Data and methods that operate on that data are contained in one place
Commonalities put into super-classes
Code reuse through hierarchies
Inheritance and delegation
Strong-typing
Compile-time type checking
Runtime type checking

7. <Please “click” Yes or No, using the menu-bar>
Poll
Are you familiar with Object-oriented Programming concepts?
Type
Class
Data members and methods
Interface
Inheritance
Polymorphism
Objects
<Please “click” Yes or No,
using the menu-bar>

8. <Please “click” Yes or No, using the menu-bar>
Poll
How many using SUPER-PROCEDURES?
<Please “click” Yes or No,
using the menu-bar>

9. Similarities between Classes and Procedures
Procedure files (.p)
Class files (.cls)
Define variables
Data members
Internal procedures
VOID methods
User defined functions
Other methods
Code in main block
Constructor
Super-procedures
Inheritance

10. Interoperability Procedures and Classes
Can NEW a CLASS
Can DELETE an object
Invoke methods using object reference
Can pass object reference as a parameter
Classes
Can RUN a procedure
Can invoke internal procedure / udf using procedure handle

11. Agenda Introduction and goals of OO in the 4GL Concepts and overview
An example
Tools support for OO in the 4GL
Beta use cases

12. Object-Oriented Concepts
What do I need to understand before I learn OO4GL?
OO terminology for familiar concepts
Classes, types, data members, methods & objects
Encapsulation
Grouping data & behavior together
Inheritance
Re-using and extending code
Delegation
Letting contained objects do their own work
Polymorphism
Generic code for objects with common data & behavior
Interfaces
Implementing a standard set of methods
The OO4GL is a set of 4GL language extensions that together allow programmers to do object-oriented programming using the 4GL. These enhancements along with the current 4GL language provide a more usable basis for writing applications that conform to the OpenEdge Reference Architecture (OERA) and support the service oriented programming model.
The OO4GL introduces a couple of new constructs within the language. First is the new CLASS construct which can be used to define new user-defined types in the 4GL. The classes defined by the CLASS construct contain both data and methods. Class definitions support single inheritance of other classes. Classes may implement one or more interfaces. Interfaces are supported using the new INTERFACE construct which allows the programmer to define a set of methods for which the class implementing the interface must provide.
The OO4GL should make it possible to have a language that is as powerful and easy to use in developing distributed, service-oriented applications, as the original 4GL language did for host-based applications, that is, these enhancements will extend the core values of the 4GL.
In understanding the features of the OO4GL it is important to understand the key concepts of object-oriented programming. This section is a brief introduction to object-oriented programming.
Object-oriented programming is a programming model organized around "objects" rather than "actions". Conventional procedural programming normally takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic. Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. The fundamental advantage of object-oriented programming is that the data and the operations that manipulate the data (the code) are both encapsulated in the object. Objects are the building blocks of an object-oriented program. A program that uses object-oriented technology is basically a collection of objects.

13. Types Each class represents a new data type Allows for strong-typing
A Type is a definition
Each class represents a new data type
Variables, parameters, return types
Allows for strong-typing
Early binding - types determined at compile time
Type-consistency enforced at compile time and runtime
A type depicts the state and behavior of an object. Types are not concerned with implementation aspects of objects. This is the purpose of classes. Types specify the structure and semantics of values while classes specify the implementation aspects. Types are used to enforce strong-typing.
Each user-defined class essentially represents a new data type. As a group these user-defined types are referred to as classes.
Classes can be used as variables, parameters, and return types. You can define a column of a temp-table as a class reference but you can’t define a column of a database table as a class reference. The initial value of an object reference is the unknown value.

14. Types – An Example Types: Order Order InternalOrder ExternalOrder is a
Sub-Type of Order
ExternalOrder
Order
is a
is a
InternalOrder
ExternalOrder
The type is concerned with the state and behavior of an object, and not the implementation (the class).
A Sub-Type can appear anywhere a Super-Type is expected

15. Benefits of Types Compile time checking for type consistency
Strong Typing
Compile time checking for type consistency
myObj = mySubObject. (must be Sub-Type)
myObj:method(…). (validates signature)
myObj:data = 3. (validates data type)
Results in safer, bug-free code because all code paths checked at compile time
Develop super-classes first
Classes in OpenEdge are strongly-typed. Strong typing means that the class definition and any references to the class are checked for validity at compile time. Compile time validation is a key advantages of programming with classes.
In order to support strong typing, either the source files or r-code for all classes in an application must be available at compile time. When you are compiling a class that extends a class hierarchy, all the classes and interfaces for the hierarchy must be available either as source files or r-code.
Additionally the compilation of a sub-class forces the recompilation of any class or interface in its class hierarchy that has changed or for which r-code is not available. Since a class is built from all of the classes and interfaces in its hierarchy it is imperative to make sure that the entire hierarchy is up to date. If any class or interface in the hierarchy cannot be compiled, the compilation of the sub-class fails.
The compiler can handle compilation of a set of classes in any order as long as either the source or r-code can be found for all referenced classes. The compilation of a class can cause many other class files to be compiled, and the compilation of a procedure that uses classes can cause those class files to get compiled as well.

16. Class Class: Order A Class defines and implements a user-defined type
A Class implements a Type
Class: Order
orderNum AS INT
custNum AS INT
CalculateTotalPrice( )
PUBLIC:
CreateOrder( )
UpdateOrder( )
GetOrderTotal( )
Next( )
A Class defines and implements a user-defined type
A Class is a template (blueprint) for an object:
Data
Methods
Relationships to other classes
Methods Data

17. The CLASS Construct CLASS [<package>.]<class-name>
[INHERITS <super-type-name> ]
[IMPLEMENTS <interface-type-name>
[,<interface-type-name>]…]
[ FINAL ]:
[ <data member> …]
[ <constructor> ]
[ <method> … ]
[ <destructor> ]
END [ CLASS ].
Filename must be same as the type-name ([<package>.]<class-name>)
Without the .cls extension
Package must map to directory structure
The source file for a class must have the .cls filename extension. The first compile-able line in the file must define the class using the CLASS statement. The CLASS statement is only valid in a file with the .cls extension. The name of the .cls file must always match the type name of the class defined in the file.
<data-member>, <constructor>, <method> and <destructor> can occur in any order.
The CLASS statement can be terminated with either a period (.) or a colon (:).
The class as a whole must be terminated by the END [CLASS] statement.
FINAL The FINAL option means this class cannot be inherited.
<data-member> A class can define zero or more data members of the class.
<constructor> A class file can define a constructor for the class.
<method> A class file can define zero or more methods of the class.
<destructor> A class file can define a destructor for the class.
The following slides discuss each of the options in more detail.

18. The CLASS Construct CLASS [<package>.]<class-name>
[INHERITS <super-type-name> ]
[IMPLEMENTS <interface-type-name>
[,<interface-type-name>]…]
[ FINAL ]:
[ <data member> …]
[ <constructor> ]
[ <method> … ]
[ <destructor> ]
END [ CLASS ].
Use packages to group classes
Package maps to physical file relative to PROPATH
at compile time AND run time
Period “.” maps to slash “/”, “\” in directories
CLASS Acme.Inventory.Order: …

19. The CLASS Construct
Use inheritance to abstract out common data and functionality
Sub-classes inherit all data members & methods from their super-classes
Sub-classes may extend or change behavior by overriding methods of super-class
CLASS [<package>.]<class-name>
[INHERITS <super-type-name> ]
[IMPLEMENTS <interface-type-name>
[,<interface-type-name>]…]
[ FINAL ]:
[ <data member> …]
[ <constructor> ]
[ <method> … ]
[ <destructor> ]
END [ CLASS ].

20. The CLASS Construct Classes are always PUBLIC
CLASS [<package>.]< <class-name>
[INHERITS <super-type-name> ]
[IMPLEMENTS <interface-type-name>
[,<interface-type-name>]…]
[ FINAL ]:
[ <data member> …]
[ <constructor> ]
[ <method> … ]
[ <destructor> ]
END [ CLASS ].
Encapsulation through class members:
Data
Methods
Access types:
PUBLIC
PRIVATE
PROTECTED

21. The Class File Filename consists of package and class name
One class per file
.cls extension
Compiles to r-code

22. Creating Class Instances
The NEW statement (equivalent to RUN)
Example
<obj-ref> = NEW <type-name> ([<parameter>[,…]])
[ NO-ERROR ].
DEFINE VARIABLE myOrder AS
Acme.Inventory.Order NO-UNDO.
myOrder = NEW Acme.Inventory.Order ( ).
The NEW statement is used to create an instance of a class, and assign the object reference for that instance to a variable or field.
Comparable to running a persistent procedure using the RUN statement.
<obj-ref> = NEW <type-name> ( [ <parameter> [, … ] ] ) [ NO-ERROR ] .
The syntax of the NEW statement is:
Where
<obj-ref> - the name of a variable defined for a class using the DEFINE VARIABLE statement. The class name used in the variable definition must match the <type-name> as defined below.
<type-name> - the name of the class and must contain the relative path, if any, from PROPATH. This name must be one of the following:
The name of the class specified in the DEFINE VARIABLE <object-ref> statement
The name of a class which is a sub-class of the class specified in the DEFINE VARIABLE <object-ref> statement
The name of a class that implements the interface specified in the DEFINE VARIABLE <object-ref> statement [ <parameter> [ ,<parameter> ]… ] are the parameters of the constructor.

23. Agenda Introduction and goals of OO in the 4GL Concepts and overview
An example
Tools support for OO in the 4GL
Beta use cases

24. Object-orientation – An Example
Application needs to manage two sets of orders for the same items:
Customer orders
Need to check valid customer and credit-limit
Charge
Shipping and logistics
Internal orders
Need to check valid department and cost center
No charge
Internal delivery
Inventory is common

25. Access Levels Accessible by super-class only Class Order Private
DEF PRIVATE VAR OrderNum AS INT
DEF PRIVATE VAR CustNum AS INT
DEF PRIVATE VAR ShipDate AS DATE
DEF PRIVATE VAR OrderStatus AS CHAR
METHOD PROTECTED … calculatePrice()
METHOD PUBLIC VOID calculateTax()
METHOD PUBLIC VOID initOrder()
METHOD PUBLIC VOID updateOrder()
METHOD PUBLIC CHAR getCustomer()
METHOD PUBLIC CHAR getShipDate()
METHOD PUBLIC CHAR getStatus()
METHOD PUBLIC DEC getOrderTotal()
Private
Protected
Accessible by super- class & sub-classes
The PRIVATE data members & methods of a super-class cannot be accessed by sub-classes. However, there is one more access-level that applies to inheritance, called Protected. Data members and methods that are protected can be accessed by sub-classes.
Public
Accessible by super-class, sub-classes & other classes

26. Inheritance Hierarchy
Class Order
DEF … OrderNum AS INT
DEF … CustNum AS INT
DEF … ShipDate AS DATE
DEF … OrderStatus AS CHAR
METHOD … calculatePrice()
METHOD … calculateTax()
METHOD … initOrder()
METHOD … updateOrder()
METHOD … getCustomer()
METHOD … getShipDate()
METHOD … getStatus()
METHOD … getOrderTotal()
InternalOrder Class
INHERITS Order
DEF … CostCenter AS INT
DEF … Department AS INT
METHOD … getCostCenter()
METHOD … getDepartment()
Inherit
from
ExternalOrder Class
INHERITS Order
DEF … CustNum AS INT
DEF … CreditLimit AS DEC
METHOD … verifyCredit()
METHOD … getCustNum()
The above class “Order” handles orders in general. An external customer might place an order, but there may also be a need to handle internal orders from employees. Above we have created two classes to handle this: InternalOrder & ExternalOrder.
The InternalOrder class has some additional attributes and methods for handling Cost Center & Department. This class will need to override the base class’ “initOrder()” and “updateOrder()” methods to initialize and update these new attributes in addition to what those methods already do.
The ExternalOrder class has additional attributes and methods for tracking the customer who made the order and the credit status of that customer. This class will also have to specialize the behavior of initOrder() and updateOrder(). The initOrder() method will have to include a call to checkCredit() before the order can be submitted. Otherwise, however, the initOrder method will be the same for both internal & external orders, so the rest of the code can be re-used as is.

27. Polymorphism
These objects of class types derived from Order may each behave differently when sent the InitOrder() message:
myInternalOrder
CostCenter = 9145
Department = 5
myExternalOrder1
CustNum = 10
CreditLimit = 50000
myExternalOrder2
CustNum = 11
CreditLimit =
if isValid(getCostCenter() and
getDepartment())
then call super-class’ initOrder()
else call super-class’ rejectOrder()
InitOrder
[CONTAINS BUILDS]
The objects above are instances of classes derived from Order: InternalOrder & ExternalOrder.
[CLICK] The derived classes both override the InitOrder() method. When the InitOrder message is sent to each object, the resulting behavior is different for InternalOrder than it is for ExternalOrder. The InternalOrder object gets the cost center & department & checks them for validity before initializing the order. It then uses the super-class’ initOrder method to do the actual initialization. The ExternalOrder checks the customer number & credit limit before initializing the order.
If (isValid(getCustNum()) and
verifyCredit())
then call super-class’ initOrder()
else call super-class’ rejectOrder()
InitOrder

28. Delegation Class Navigator Class GuiHandler FirstButtonPressed()
LastButtonPressed()
NextButtonPressed()
PrevButtonPressed()
OkButtonPressed()
CancelButtonPressed()
Class Navigator
GuiHandler myGui
QueryHandler myQuery
initNavigator()
First()
Last()
Next()
Prev()
Cancel()
OK()
Contains
Class QueryHandler
OpenQuery()
CloseQuery()
GetFirstRec()
GetLastRec()
GetNextRec()
GetPrevRec()
[CONTAINS BUILDS]
Above is a (very simplified) Navigator class. The Navigator class could be used for any frame, whether it’s a window that displays the details of a specific record, a browser that highlights a specific row within a grid, or anything else that requires next, prev, first, last, etc..
The Navigator class receives events when its next, prev, first, last, cancel or ok buttons are pressed.
[CLICK] It delegates the handling of these events to its GUIHandler object, which takes care of adjusting the GUI to reflect the button that was pressed, and also to its QueryHandler, which adjusts the data to reflect the button that was pressed.
[CLICK] For example, if the next button is pressed, the QueryHandler might call its QUERY-NEXT method so that the next record will become current, and the GUIHandler will call its NextButtonPressed() method which will cause the new current record to be displayed.

29. Agenda Introduction and goals of OO in the 4GL Concepts and overview
An example
Tools support for OO in the 4GL
Beta use cases

30. Tools Support For OO in the 4GL
OpenEdge Architect
Code editors
Tools for Business Logic
Business Entity Designer
OpenEdge Studio (AppBuilder)
4GL Development System (Procedure Editor)
Application Compiler
Debugger
Compile  Debug requires stub
Not in this beta
OpenEdge 10.1A extends the Progress 4GL with the introduction of Object-Oriented 4GL (OO4GL). OO4GL introduces a new type of source code file called the OO4GL Class file, with an extension of “.cls”.
There are also new rules for working with this new source file type.
To support development with the OO4GL, several ADE tools have been enhanced to provide support for .cls files, allowing the Procedure Editor, the Procedure Window, and the Application Compiler.

31. Rules For .cls Files Must have .cls extension to compile
All editing environments
Must have .cls extension to compile
Added to file filters
File and package name in class file must match physical location
Must save file to run
CLASS payroll.taxcalc: …
END CLASS.
There are some important rules for working with OO4GL source code, which apply in all editing environments:
The compiler requires that a 4GL Class file must have a .cls extension. To support this, the “*.cls” extension has been added to the appropriate filters for any Open or Save As dialogs. The .cls extension is NOT “enforced” when saving a class file, however, since this would be different to how other source file types (.w, .p) are handled - they do not enforce filename extensions.
The definition of the 4GL class within the .cls file identifies the filename of the class and optionally the relative path to the file. The compiler requires the type-name ([<package>.]class-name) to match the physical file location (relative path and filename) of the file when it is compiling (for running, not for syntax checking – see later). This differs from the existing source file types, where the path and name of the file being compiled is irrelevant to its content. e.g.
In the following program:
CLASS payroll.taxcalc:
...
END CLASS.
“payroll.taxcalc” represents the path and name of the class. The pathname of this file must end with “payroll\taxcalc.cls” for the compiler to treat this file as a valid OO4GL class file e.g. c:\openedge\payroll\taxcalc.cls, c:\payroll\taxcalc.cls or c:\openedge\wrk\payroll\taxcalc.cls.
The implication of this is that to run the code (which requires compiling), the file must be saved with a path that matches that specified in the CLASS statement of the file.
The path to the file, as specified in the .cls file, does not need to be a part of the PROPATH.
The file does NOT need to be saved in order to perform a syntax check (see later).

32. AppBuilder Support No AppBuilder changes to support class files
Procedure Window
No AppBuilder changes to support class files
Opened as unstructured procedures in Procedure Window
AppBuilder Procedure Window
Same support as Procedure Editor
Procedure Window supports remote development
Web-disp.p cannot instantiate class files
There is no additional functionality provided in the AppBuilder to handle .cls files. The AppBuilder treats .cls files as unstructured procedures, which can be manipulated in the Procedure Window. Open a class file, or drag and drop one on to the AppBuilder, and the Procedure Window is opened. The Appbuilder uses the “.cls” extension to determine to open the Procedure Window; it does not attempt to parse the file.
The “*.cls” file filters have not been added to the AppBuilder.
Putting OO4GL in an AppBuilder structured window (.p, .w, .i) will generate appropriate errors. These errors have not been sanitized, so the filename in any errors could be a temporary file (and not a class file).
One of the key differences between the Procedure Editor and the Procedure Window is that the Procedure Window allows users to work on remote files i.e. it can open, save and execute files on a WebSpeed Transaction Server.
There have been no changes to WebSpeed 4GL code (such as web-disp.p) to allow invoking .cls files directly from WebSpeed. However, you can write a WebSpeed program that instantiates a class, and so there is a need to have access to .cls files on the WebSpeed Transaction Server. Therefore there has to be some provision for remote development support of class files. Running a .cls file in remote development mode will not work since it is not a web object. Running remotely means executing the program on a WebSpeed agent. The only procedures that can be run correctly on a WebSpeed agent are web objects (procedures with the necessary WebSpeed-enabled infrastructure included). The Procedure Window spawns a browser and initiates a web request to the WebSpeed Transaction Server in order to run the program. If the user runs a .p or .w that is not a web object, the browser will end up displaying some sort of error when the agent fails to run the program correctly (the error does not explain what the problem is). As we do not stop users from remotely running .p or .w files that are not web objects, neither do we not stop users from running .cls files remotely.
When checking the syntax of a derived class in remote development mode, the base classes must be in the WebSpeed agent’s PROPATH, otherwise the syntax check will fail. This is analogous to having the agent’s PROPATH correct for include files in .p and .w files.

33. Procedure Editor Support
File filters
New “*.cls” filter in GUI
File open
Save
Save As
Source file types
All Source (*.p, *.w, *.i, *.cls)
Classes (*.cls)
TTY has no filters
The Procedure Editor allows users to create, open, save, check syntax, and run a .cls file. It does not provide any suggested filename when saving an untitled edit buffer to disk, whether a .p, .w, or .cls; this remains unchanged.
Opening Files: The filters in the GUI Procedure Editor’s Open File dialog contain the .cls extension as a source file type, one for All Source (*.p,*.w,*.i,*.cls) and one for Classes (*.cls).
Once the Procedure Editor opens the .cls file, it performs the necessary internal initialization to render the .cls file as a source file (e.g allowing syntax coloring in the GUI editor) in a new edit buffer. This will work for all mechanisms of opening the .cls file (e.g. File->Open, F3, drag-and-drop of the file, opening from the MRU list, opening from Windows Explorer), as it does for .p or .w files.
Saving Files: Same filters added for opening files applies to Save and Save As options.
TTY: The TTY Procedure Editor’s Open File dialog, Save Dialog and Save As dialog, do not have a filter mechanism, and so no change here.

34. Syntax Checking Checking syntax of named edit buffers
Create temp directory(s)
Contains class file of correct name
Checking syntax of unnamed edit buffers
Saves to temp file of .cls extension
In current working directory
An inherited super-class must be in PROPATH for sub-classes to syntax check
In order to syntax check a file - regardless of the extension – the procedure editor has to first save the file. For .p, .w files the contents of the edit buffer can be saved to a temporary file (e.g. p12345.ped), compiled, and then removed after compilation.
Temporary files and directories are saved to the –T parameter location, or to the current working directory.
When checking the syntax of a class file it too needs to be saved to a temporary file first, but things are a more complicated since the class name (and the path, if entered) referenced in the .cls file must match the physical name on disk. Therefore, the procedure editor does the following.
First, the file is written to a temp-file in the current working directory (unless already compiled or syntax checked, the compiler does not initially know the name or type of the file being syntax checked); this has a file name of format p12345.ped, i.e. same as for a .p or .w file. If this fails to compile (if it is a class then it will fail since it does not have the .cls extension) then an appropriate error is returned indicating that the file is a class. In this case, the file is re-saved as a temporary file with a file name format “p12345.cls”; this will still fail to compile since the filename does not match the class name, but at this point the compiler now has access to the CLASS-TYPE attribute of the COMPILER handle, and so to the class which provides the actual path and correct name of the physical file. At this point, a temp directory is created named with a format of “p12345” and any required sub directories are created as defined in the class file itself, along with a file of the correct name and .cls extension. For example, a class with a name of “payroll.taxcalc.payclass” would be created as: “p12345/payroll/taxcalc/payclass.cls”, where p12345 is the temporary directory name. This file is compiled and any errors reported. Temp files and directories are removed when the compiler has completed its work. (Note: p12345 is used as an example name only.)
When checking the syntax of a inherited class, the inherited class must be in the user’s PROPATH, otherwise the syntax check will fail. This is analogous to having the PROPATH correct for include files in .p and .w files.
As pseudocode:
If file is a .p/.w, or untitled edit buffer
Compile as .ped
If (is oo4gl class file error message)
Save as .cls /* compile-file */
Flag as.cls
If (is .cls)
Compile .cls file /* compile-file */
If (package doesn’t match error)
Remove existing compile-file (including dirs, if necessary)
Rename .cls file (including building dirs) /* compile-file */
Remove compile-file
Return compile output

35. Running a Class File – Stub Program
Stub program instantiates the class
DEFINE VARIABLE myInternalOrder AS CLASS
Acme.Inventory.InternalOrder NO-UNDO.
DO ON ERROR UNDO, LEAVE
ON ENDKEY UNDO, LEAVE
ON STOP UNDO, LEAVE
ON QUIT UNDO, LEAVE:
myInternalOrder = NEW
Acme.Inventory.IntenalOrder().
END.
DELETE OBJECT myInternalOrder NO-ERROR.
After all that checking, it’s not the class that gets run from the Procedure Editor!
Rather, the Procedure Editor generates a temporary “stub” program to instantiate the class, and runs this stub, which in turn executes the .cls file.
The Procedure Editor will remove the stub file once the execution of the class is complete.
The stub procedure does not allow for class files whose constructor requires parameters. If the constructor for the class requires parameters, the 4GL client will generate an error when running this stub program when it tries to instantiate the instance of the class (akin to a “Mismatched parameters” error but for a constructor). As with a .p/.w that requires parameters, you have to write your own calling procedure to call a class with parameters.
The Procedure Editor and Procedure Window need a way to determine the package name of the .cls file, in order to compile it correctly, and to build the stub file for running. A new CLASS-TYPE attribute on the COMPILER handle has been implemented to do this, which returns the package name. Compile a .cls file with an incorrect name and the compiler will return error (12629), and will set the COMPILER:CLASS-TYPE attribute to the name defined in the .cls file.

36. Application Compiler Includes ‘.cls’ extension
May compile super-classes
“Remove Old .r Files”
Super-classes .r is not removed when compiling sub-classes
“Only Compile if No .r File”
The Application Compiler supports the compiling of .cls class files, in both GUI and TTY clients. The Application Compiler’s default “File Type” filter now contains the .cls extension as well as .p and .w. The application compiler saves the default file type filter in to the registry/ini, and if this has been saved without the .cls then you will not see the .cls extension in the Application Compiler window (until added and saved); this also applies if an .ini file from a previous release of OpenEdge that does not support .cls files.
The Application Compiler has not been changed to allow for any re-compiling that may need to be done for .cls files, although the compiler itself has in support of strong typing.
If compiling a sub-class, the compiler also compiles any super-classes. This is a function of the compiler, and NOT the application compiler. If more than one sub-class derives from one super-class, then the Application Compiler might recompile the super-class for each sub-class.
If “Remove Old .r Files” is specified, the Application Compiler will check for any existing .r file for each file before it compiles the file. If the .r file exists, the Application Compiler removes the .r file for that file. If the file is a sub-class .cls file, the Application Compiler will not remove the .r files of any super-classes as part of that operation. If the Application Compiler was to try compiling the super-class after the sub-class, it would remove/replace the super-class’s .r file.
If “Only Compile if No .r File” is specified, the Application Compiler will check for any existing .r file for each file before it compiles that file. If the .r file exists, the Application Compiler skips compiling this file. If there is no .r file, the file will be compiled; if it is a sub-class, then any if it’s super-classes will be compiled regardless of whether .r code exists or not. This is the behavior of the compiler itself and not of the Application Compiler utility, and is likely to be enhanced in future releases to prevent unnecessary recompilation of super-classes, through use of a digest maintained to identify which code does not need to be re-compiled.

37. Agenda Introduction and goals of OO in the 4GL Concepts and overview
An example
Tools support for OO in the 4GL
Beta use cases

38. Current Beta Use Cases (1/4)

39. Current Beta Use Cases (2/4)

40. Current Beta Use Cases (3/4)

41. Current Beta Use Cases (4/4)

42. In addition, you shall … Validate interoperability
Gather information about increase in development / maintenance productivity
"Benchmark" runtime performance through testing of your user-defined classes
Share your findings
Multiple ways to design, organize any given functionality

43. In Summary Standard OO concepts available in the 4GL
Built on top of existing 4GL constructs
Interoperability with Procedure / Functions
Can be combined with procedural programming, not all or nothing
Many benefits in OO Programming
Major difference of OO: Enforcement

44. Questions?

45. Thank you for your time!