OO Wish List

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.


  • Passing at least error return objects across the Appserver boundary; could be all objects. Might not include OpenClient, see below.
  • Support for enums with bitwise operators.
  • Package level protection.
  • Support for collections, maps, and lists.
  • Singleton, single run classes on AppServer.
  • Callbacks that now require procedures to support class methods.
  • Character expression use to identify a class, not a type name.
  • Define a property LIKE a database field.
  • Use // for a single line comment.
  • Enable .NET and Java OpenClient to access OOABL classes with singleton, single run like other Appserver calls above.
  • Tooling impact (on ESB/BPM/BRM) for calling object.
  • Reflection for internal members of a class. Added by the audience as being of higher priority than full reflection, see below.


  • Remote instantiation and remote invocation - should this be done? (Sentiment at the IE seemed to be against it)
  • Support full reflection.
  • Java-like data types, i.e., class version of primitives - Integer vs integer in Java terms.
  • OO equivalent for -p. Question: should this be accompanied by a "main" for code to be initially executed once the object has been instantiated.
  • Ability to invoke DLL/SO as method, not procedure.
  • Expand public access to include database related structures, i.e., TTs and PDSs.
  • Objectification of key built-in objects (sockets).
  • Support of object reference:class member syntax in ABL constructs, i.e., make colon syntax available in existing parts of the ABL.
  • DEFINE and other statements like Java, i.e., multiple variables of the same type defined in one statement.


  • Persistence of objects to text, JSON, XML, to disk, etc. and reconstitution of the object from the saved form, aka serialization and de-serialization. Several people would place this high on the list and would prefer it to actually moving the object across an AppServer boundary.
  • Garbage collection to handle circular references and pub/sub links.
  • Override properties and shadow data members.
  • Generics. I would push this higher because the use in frameworks.
  • Annotation.
  • Objectification of TT and PDS, i.e., ability to subclass and add data and methods.
  • Objectification of all OE builtin objects.
  • Allow non-PLO objects in temp-tables.
  • Allow TT indexes on object properties.

Last Set

  • Inner classes.
  • Indexed properties.
  • Explicit interface member implementation.
  • Output to longchar, mem-pointer, etc.

First Audience Suggestions

  • Anonymous methods. (Peter Judge)
  • Coding shortcuts, e.g., ++ (mentioned in the IE, but somehow didn't make the list)
  • Objectification of key built-in objects like TT and PDS (Simon Prinsloo)
  • Data Connection Object for OE, SQL, DDC, and MOM. (TMH)

Second Audience Suggestions

  • Enums as a data type.
  • BIND and By REFERENCE in interfaces.
  • Simplification of VALID-OBJECT and VALID-HANDLE.
  • Operator overload (fat chance).
  • Subscribe to named events from classes.
  • Making everything OO is important for training new programmers.
  • Strict mode for compilation.
  • PL level protection; implies signing PL.

Votes at PC EMEA

  • Serialization like WRITE-JSON. 6
  • All things to remove .ps from application. 11

    * Run on Appserver.

    * Callbacks.
  • Subscribe to named events in classes. 2
  • Collections. 8
  • Generics. 5
  • Passing object as parameter. 1
  • Enums. 8
  • Strongly typed objects in TTs. 2


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
simon@vidisolve.com's picture

Objectification of key built-in objects

Simon L Prinsloo
Vidisolve (Pty) Ltd (www.vidisolve.com)

I would like to see more than just Sockets as "Key". My list would be:
1.1 Temp-table and Dataset
1.2 Socket and Socket Server
1.3 File-info. It may be argued that .Net already have similar objects, but I use this one most of the time on the AppServer in Linux.
2. Sax Reader and Sax Writer

There after it may be handy to have SESSION, COMPILER and maybe ERROR.

In the Other list above we have:
"Objectification of all OE builtin objects."
My question is why all of them? Sure it might be nice to be able to reference the old UI widgets as object, but is it really worth the effort or can the time be spent better on other stuff we need? Some of the ones left in the list may still make sense, but I am not sure if ALL make sense.

If we make Procedure handles objects, will that enable us to invoke procedures as if they are VOID methods? If not, why bother? If yes, just think of the pretty spaghetti we will see after everybody started to simply reference the persistent procedures as objects...

tamhas's picture

Simon, I would agree that

Simon, I would agree that your comments are on the mark. The one counter I can make is that clearly they would never be done all at once and that prioritization is likely to mean that there are some which might never get done because they are so low priority that there is little point. Although, that sort of think can bite one when dealing with legacy code. It is very irritating to be rolling along being nicely OO and then suddenly have to flip to a procedural model because of some legacy part of the language. Which said, my highest priority are structural things, e.g., SAX where one has to launch a .p from the .cls. Yuck.