Code, discussions, and whitepapers related to the use of object-oriented techniques in coding ABL applications.
I was playing with OOP/ABL in v10.1A, when I noticed my class unnecessarily growing because of repeatedly creating set/get methods. Some OOP language I've seen has one liner setter/getter. I thought there should be a way of having "one-liner" (well, not really) as well for 10.1A. :-)
So here goes..enhance if you must..
/* ===================== here's the meat!!! includes/SetGet.i 1 - variable name 2 - data type ===================== */ DEFINE PROTECTED VARIABLE {1} AS "{2}" NO-UNDO. METHOD PUBLIC "{2}" get{1}():
At the 2013 PUG Challenge Americas, there was a sort of semi-spontaneous OO information exchange with Rob Holzel, Evan Bleicher, and Shelley Chase.
I repeated this session at the 2013 PUG Challenge EMEA with assistance from Peter Judge, Rob Straight, and Shelley Chase. what follows is the result of these two sessions.
The new OO features in 11.3 include:
With the usual disclaimers of no promises and no schedule, we reviewed a list of additions to OO which had been requested at one time or another and solicited additions to this list from the audience. Below is the combined list in four categories - Roadmap, Next, Other, and Last Set (interpretation is left to the reader and qualifications about no promises and no schedule clearly apply). There is no significant to the order within category. Priorities are likely to change over time and may be dependent both on the perceived value and the ease of implementation. There have been indications that upgrade of OO may be a higher priority now than in the past so items farther down on this list may not be as distant as one would have assumed them to be in the past, but again, nothing one can count on. There are always limitations in budget and personnel and competing priorities.
Progress Software has numerous references in documentation and whitepapers to the parallels between superprocedures and classes, including a fairly lengthy, if somewhat flawed example in the Getting Started: Object-Oriented Programming manual for 10.1A that shows two parallel examples, one worked using superprocedures and one worked using classes. However, what is not shown is an example in which a class replaces a superprocedure while retaining the original program structure as a set of procedures. For a local super-procedure, this substitution is simple because the class does not need to be accessible except from the procedure that instantiates it. For a session superprocedure, a different functionality is required because the internal procedures of the session superprocedure become a part of the name space of procedures that did not invoke the superprocedure.
One of the problems faced by ABL programmers for many years is the lack of a true exception handling mechanism in the language. By “exception handling”, we mean a mechanism by which a program encounters an error or unexpected condition then can communicate up the call stack with the purpose of:
1. Signaling that requested execution has not completed as expected;
2. Communicating any necessary information about the details of why this condition occurred; and
3. Providing a structure such that the condition is “handled” in a graceful fashion at an appropriate level in the code.
In developing a foundation framework for Object-Oriented ABL, it seems natural to consider creating a set of Collection classes since they have a broad utility in OO design in other languages. It also seems natural to consider imitating the Collection classes in Java since that is a tried and true implementation into which there has been a considerable investment of thought and effort.
This group will serve as a focal point for discussions, examples, and projects intended to help people utilize the object-oriented language features which became available in OE10.1. The intention is to:
1) Develop established object-oriented design principles in a way that is consistent with a 4GL;
2) Provide OO-based contributions to OERA-compliant architectures; and
3) Assist in the utilization of OO techniques in the context of existing procedural code.
Contributions to this purpose will include white paper discussions, code fragments illustrating techniques, and complete model components to use in building applications.