img-002

Abstract Data Types in OpenEdge
Internship training project


by Valentin Duricu


By being constantly involved in the training/mentoring process to hire new junior OpenEdge developers, I try to find ways to introduce interesting and awesome stuff from an interesting language, mostly used by applications older than myself.


Even though Progress has recently started to buy, integrate and add new features into OpenEdge, the majority of the commercial products are using older versions of OpenEdge or, if they upgraded to latest version, they do not use the newly added functionalities.
That is a big problem for us trainers, because we have to teach outdated stuff for outdated products and most interns won't be interested in applications like these.

I fully understand that projects won't always use the latest and greatest, but we can bring some features from other languages that most juniors know into the OpenEdge world. Some of these are the Abstract Data Types or ADTs for short.
The ADTs won't bring efficiency in working with data in OpenEdge, but they help understanding how a temp-table can be used and to make the transition from classical lists/maps to a temp-table way of working.

To be able to do the code

I needed a small diagram that can help me in building the 2 ADTs.
So, I've divided the work in 2 parts, as it can be seen in the diagram below:
• the ADTOE_Common part - where my temp-table definitions reside;
• the ADTOE part - where the actual ADTs are.
In the ADTOE_Common part you can see that there are 5 temp-tables defined: ttIntMap, ttIntList, ttGenericMap<>, ttGenericList<> and ttStringList. The TKey and TValue templates are just notation in the diagram, in the actual files I used named include arguments.
For the second part, ADTOE, there can be 2 ways of working: Procedural or Object Oriented. Note: No matter which way of working you choose, you must test your code.

You can look at my code

I've created 4 projects:

ADTOE_Common - Holds the common parts of the project like temp-tables and datasets;
ADTOE_Proc - Holds the Procedural implementation;
ADTOE_OOP - Holds the Object-Oriented implementation;
ADTOE_Tests - Holds the unit tests of the project.
In the ADTOE_Common project I've defined all my temp-tables that I use in the ADTOE projects:

• 2 specific temp-tables (ttIntMap and ttIntList),
• 2 template temp-tables that use include arguments and allow the developer to personalize the Map and List temp-tables as he/she wants,
• 1 temp-table for a String List that uses the template list temp-table.
The ADTOE_OOP project has to be implemented. To implement the solution in the OO way you can have a look at the procedural implementation and transform it.
(PS: The code will be in branch full_implementation)
The ADTOE_Proc project follows the implementation described above:

• One specific implementation for the ProIntList - the list that holds integer values,
• One generic implementation for the ProGenericList that takes one include argument named listType,
• A list that holds string/character values, based on the ProGenericList,
• One generic implementation for the ProGenericMap that takes two include arguments named key-dataType and value-dataType,
• A map that has string/character key and value, based on the ProGenericMap.
If you have any question regarding this feel free to drop me an email: valentin.duricu@wayfare.ro

About me

I have been working in software development for 8 years (using PHP, Javascript, Java, C#, MySQL, Python...), 5 of them at Wayfare - mostly as an OpenEdge developer. I like trying new and interesting things in every language that I used and I also like to try to bring the most interesting features from other languages into the OpenEdge world.

Leave a Reply

Your email address will not be published. Required fields are marked *