The OpenEdge Hive

OOABL “Wish List”

Revised 8 June 2007 to drop features added in 10.1B and include relevant items from the comments through that date.

Additions I would like to see to OOABL include (not in priority order):

• Object equivalents for primitives, e.g., Integer versus integer. This is important for providing methods that can handle both objects and primitives without requiring duplication of classes and methods;
• The ability to put objects into a temp-table and sort on their “values” instead of their handles, i.e., some implementation of the Comparable interface;
• An OOABL equivalent to generics (parametric polymorphism). This would greatly simplify a number of types of library construction;
• Strongly typed events such as the agents and events as described in the 10.1A beta docs.
• Collections – while a full-featured implementation of collections is certainly a key building block, it is also a capability for which a fairly reasonable workaround exists (see http://www.cintegrity.com/downloads.html for code). With generics, method overloading, and object equivalent for primitives, a workaround could be reasonably complete and elegant without any new language features;
• A more complete implementation of reflection, although I am a little afraid of what some people might do with it to get around the OO compile-time controls;
• Exception/Condition Handling, preferably in the form of a block structure, not Try... Catch... Finally. I realize that I am probably swimming upstream here, but I hope that PSC will give some consideration to the option of attaching exceptions to blocks rather than using the Java syntax. "Try" has got to have been the worse choice of keyword ever. See the discussion at http://www.cintegrity.com/PDF/ExceptionStack.pdf . The code that accompanies this whitepaper doesn’t actually handle exceptions per se, since that takes a language change, but it does provide a structure for passing messages up the call stack. One of the aspects of it that I think should be interesting is that it goes beyond "exceptions", i.e., semi-fatal failures, to include cases where it is merely the case that something has occurred that might be worthy of note or caution, but which may well be perfectly OK, especially in some contexts. This is the kind of richer functionality which would be very nice to include in an OO4GL;
• Better object deletion capabilities, i.e., some version of garbage collection;
• Controllable, automated object serialization, although this is not difficult to implement manually. This might be extension of WRITE-XML() and READ-XML() functionality to objects, but all implementations of these methods should include an option to suppress the header. This relates strongly to transfer of objects across the AppServer and the Sonic/JMS boundary.
• Static or class data members and methods;
• ProDataSet methods to enable relational to object mapping;
• True singletons (see http://www.cintegrity.com/PDF/ReplaceAnSPWithAClass.pdf for a workaround);
• Import statements;
• Interface extension through inherits;
• Multi-threaded sessions – very important for creating powerful services in an SOA. See http://www.cintegrity.com/PDF/Multi-threadingUseCase.pdf for more discussion;
• Highly performant interprocess communication would be a second best, if we can’t get multi-threaded sessions;
• Asynchronous method invocation;
• Abstract methods;
• Source code for Sonic/JMS adapter;
• A database connection object;
• The ability to populate a ProDataSet from a SQL-92 query;
• PDS features for objects, e.g., TRACKING-CHANGES();
• OO Syntax for existing ABL objects such as temp-tables and memptrs;
• Dynamic invocation;

One point I think PSC should keep clear is that, while it is understandable and generally desirable to look to other OO languages for inspiration and standards on “how things are done”, one should also remember that OOABL is a 4GL and thus one might expect or want functionality to be implemented in a somewhat different way. Slavish imitation of Java or any other 3GL is likely to lead to 3GLing of ABL, and there has already been too much of that. A good example is provided by the discussion in the Collections whitepaper cited above, particularly with respect to Java concrete classes based on the implementation technology versus the use of temp-tables for OOABL. I would suggest that implementing functionality that enables utilizing proven OO patterns is more important that implementing it using the same vocabulary or style as is used in any given OO3GL, particularly since they are not consistent among themselves.

In this regard, I think that one of the most important barriers to break through is the single-threaded session. Whether this is done via a true multi-threaded client or “cobbled” by providing a highly performant method of interconnecting multiple sessions, it seems essential to fulfilling the SOA goals of the OERA.