The OpenEdge Hive

This page was created with the idea that it would be the beginning entry in a series of contributions by multiple authors, eventually turning into general documentation on ProDataSets. After one early contribution by Tim not much got added until Miles came along with his large contribution which covers a lot of ground. While that was a big help, I am sure there can always be more, so I have left this page as a pointer for those who might consider making contributions. What I would like in particular I am describing below:

I would like two documentation hierarchies.

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:

• Private and protected are class, not instance, i.e., appropriate members of the same class can read attributes in other instances of the same class as in other OO languages. Implies statics can also access private members of instances to which they have a handle.
• Dynamic access to Progress built-in classes, notably VST classes.
• Cleaned up chained syntax.

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.

The use of any form of Hungarian Notation is a topic certain to produce intense opinions, whether pro or con. Since CI intends to use a form of Hungarian Notation in its published examples and foundation classes, it seems worthwhile to review the reasons for this choice and the specifics of the standards that will be used.

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.