Pros and Cons of using object oriented programming for progress openedge

Question

I understand the pros and cons of using object oriented programming as a concept. What I'm looking for are the pros and cons of using oo in progress/openedge specifically. Are there challenges that I need to take into account? Are there parts of the language that don't mesh well with oo? Stuff like that.

Edit: using 10.2b

Ev

Which version of Progress/OpenEdge are you using? – Ked

One obvious disadvantage if you use OOP is when you try to generate .NET Proxy using ProxyGen for your class.Proxy Generator wont allow CLS as input and you will have to write gateway procedure to expose them. KB Article – Roughneck

Answer 1

I'll give you my opinion, but be forewarned that I'm probably the biggest Progress hater out there. ;) That said, I have written several medium-sized projects in OOABL so I have some experience in the area. These are some things I wrote, just so you know I'm not talking out of my hat:

• STOMP protocol framework for clients and servers
• a simple ORM mimicking ActiveRecord
• an ABL compiler interface for the organization I was at (backend and frontend)
• a library for building up Excel and Word documents (serializing them using the MS Office 2003 XML schemas; none of that silly COM stuff)
• an email client that could send emails using multiple strategies

OOABL Pros:

• If you absolutely must write Progress code, it is a great option for creating reusable code.
• Great way to clean up an existing procedural codebase

OOABL Cons:

• Class hierarchies are limited; you can’t create inherited (sub-) interfaces in 10.2B (I think this was going to be added in 11). Older versions of OpenEdge have other limitations like lack of abstract classes. This limits your ability to create clean OO design and will hurt you when you start building non-trivial things.
• Error handling sucks - CATCH/THROW doesn’t let you throw your custom errors and force callers to catch them. Backwards compatibility prevents this from evolving further so I doubt it will ever improve.
• Object memory footprint is large, and there are no AVM debugging tools to track down why (gotta love these closed systems!)
• Garbage collection wasn’t existent ‘til 10.2A, and still has some bugs even in 11 (see official OE forum for some examples)
• Network programming (with sockets) is a PITA - you have to run a separate persistent procedure to manage the socket. I think evented programming in OOABL was a PITA in general; I remember getting a lot of errors about “windowed environments” or something to that effect when trying to use them. PUBLISH/SUBSCRIBE didn’t work either, if memory serves.
• Depending on your environment, code reviews may be difficult as most Progress developers don’t do OOABL so may not understand your code
• If above point is true, you may face active resistance from entrenched developers who feel threatened by having to learn new things

OO is all about building small, reusable pieces that can be combined to make a greater whole. A big problem with OOABL is that the “ABL” part drags you down with its coarse data structures and lack of enumerators, which prevent you from really being able to build truly beautiful things with it. Unfortunately, since it is a closed language you can’t just sidestep the hand you’re dealt and create your own new data or control structures for it externally.

Now, it is theoretically possible to try and build some of these things using MEMPTRs, fixed arrays (EXTENT), and maybe WORK-TABLEs. However, I had attempted this in 10.1C and the design fell apart due to the lack of interface inheritance and abstract classes, and as I expected, performance was quite bad. The latter part may just be due to my poor ability, but I suspect it's an implementation limitation that would be nigh impossible to surmount.

The bottom line is use OOABL if you absolutely must be coding in OpenEdge - it’s better than procedural ABL and the rough edges get slightly smoother after each iterative release of OpenEdge. However, it will never be a beautiful language (OO or otherwise).

If you want to learn proper object-oriented programming and aren’t constricted to ABL, I would highly recommend looking at a language that treats objects as a first-class citizen such as Ruby or Smalltalk.

Ked

You couldnt hate openedge more than i do! IMHO Progress should drop the ABL and work on killer SQL and no-SQL implementations, nobody wants the ABL – Profuse

The worst part for me at least is the lack of first class arrays to allow map/queue/deck/list implementations. – Profuse

Answer 2

In the last four years I have worked 80% of the time with OOABL (started with 10.1c). I definitely recommend using OOABL but I think it is very important to consider that using OOABL the same way as in other OO languages is fraught with problems. With "the same way" I mean design patterns and implementation practices that are common in the oo world. Also some types of applications, especially in the area of technical frameworks are hard to do with OpenEdge (e.g. ORM).

The causes are performance problems with OOABL and missing OO features in the language.

If you are programming in C# or Java for exampe, memory footprint and instantiation time of objects are not a big issue in many cases. Using ABL this becomes a big issue much more often. This leads to other design decisions and prevents the implementation of some patterns and frameworks.

Some missing or bad OO features:

• No class library, no data structures needed for oo
• No package visibility as in java (internal in c#) This becomes relevant especially in larger applications
• No Generics
• Really terrible Exception Handling
• Very limited reflection capabilities (improved in oe11)

So if you are familiar with oo programming in other languages and start working with OOABL, you could reach a point at which you were missing a lot of things you expect to be there, and get frustrated when trying to implement such things in ABL.

If your application has to run on Windows only, it is also possible to implement new oo code in C# and call it from your existing progress code via clr bridge, which works very smoothly.

Allier

Answer 3

K+

Only one thing - "Error handling sucks" - it sucks, but not because you can not make your own error-classes a catch them in caller block - that works, I'm using that. What sucks is that mix from old NO-ERROR / ERROR-HANDLE option and Progress.Lang.Error / CATCH block and ROUTINE-LEVEL ON ERROR UNDO, THROW. That is a big problem, when exists no convention in team, which errorhandling and how will be used.

Ringtailed

Right. I was trying to keep it concise, but what I meant is that in Java (which is essentially what OOABL copies to the best of its ability), when I define a method that THROWs some error, and someone else calls my method, they must CATCH the potential error that I will be throwing (or alternatively re-THROW it up the call stack again). In ABL, there is no compile-time enforcement of this. Writing custom error classes in OOABL basically gives you just a custom error number and message. You do not get that nice control flow like Java, even with ROUTINE-LEVEL ON ERROR UNDO, THROW. – Ked

Or, to put it more simply, callers may never know that your method throws a custom exception (e.g. FileNotFoundException). There is no compiler message at all when calling a method that throws a custom exception. They would have to look at your source and see that your method throws an error. In Java the compiler forces you to catch or re-throw, even if you plan on ignoring it. – Ked

@AbeVoelker what you're referring to is known under the name of "checked exceptions" and it's casually placed as one of the top items on various "Java pet peeves" lists. Perhaps one of the best explanations why checked exceptions do more harm than good was presented by infamous Anders Hejlsberg: artima.com/intv/handcuffs.html Other than that I agree completely with your critical analysis of ABL, including many of your other posts here and on your blog. I wouldn't think of you as a "hater", rather a professional who cares about his toolset. – Remote

@VladGudim Thanks for the interesting article! I can see now how typed exceptions can lead to tightly coupled code. Truth be told, I only did Java in school so never have had to code with it against a large code base or written a library that others would have to use. So I should probably not spout religious opinions on the subject. Also, thanks for your kind words. I should have a new blog post coming up in a month or less, after I finish the DataMapper database adapter I've been working on (and unfortunately have to talk about the failed 0MQ binding). Peace! – Ked