SubInterfaces (OOABL)

Posted by abevoelker on 18-Nov-2010 14:51

I was working on an interface that I was hoping to make a sub-interface of a different interface.  In other words:


with bar being an interface itself.  However, I was stopped dead in my tracks by this error:

Inheritance is not supported for interfaces. (13046)
"An interface cannot inherit from another interface or a class."

Yikes.  Is this fixed / going to be fixed in another version of OpenEdge?  I'm on 10.2A right now.

All Replies

Posted by abevoelker on 18-Nov-2010 14:54

Nevermind - I found it on the online ProKB (sorry)!  Looks like it isn't going to be in until 11.0.0... sad.

ID: P163213
Title: "ABL: Does the  OpenEdge ABL support Interface inheritance?"
Created: 04/06/2010Last Modified:  04/06/2010
Status: Unverified

  • ABL: Does the OpenEdge ABL support Interface inheritance?
  • Are there any plans to  have the OpenEdge ABL support Interface inheritance?
  • When will the  OpenEdge ABL support Interface inheritance?

  • All Supported Operating Systems
  • OpenEdge 10.x

The ABL does not support Interface inheritance in  10.x.  It is on the list of items to implement in 11.0.0.

Posted by Thomas Mercer-Hursh on 18-Nov-2010 16:09

Yes, interface inheritance is on the roadmap for 11.0.  In the meantime, there is a technique using abstract classes which can accomplish a similar purpose and which is discussed on the OO forum.

Posted by abevoelker on 18-Nov-2010 16:54

That sounds perfect, but I'm on 10.2A so there are no abstract classes!  Honestly, I really wish Progress would have implemented a more complete OO implementation instead of all of this incremental stuff.  10.1C (which is what I have at work) is even worse, with the lack of garbage collection and stricter reserved keywords for class and method names.  Ah well... the grass is always greener in version n + 1 I guess.

I'll see if I can get a 10.2B evaluation version or something... at least I don't have to wait for version 11.  Thanks a ton for pointing that out!

Posted by Thomas Mercer-Hursh on 18-Nov-2010 18:15

One always wants more!   But, realistically, if they had waited until inheritance of interfaces was done, it would be mid-2011 before we would have gotten anything!

Posted by abevoelker on 19-Nov-2010 08:53

I just realized I don't think I will be able to solve this with an abstract class anyway, since the class I am implementing this sub-interface on is already a sub-class of another class.  Since OOABL doesn't support multiple inheritance like C++, I can't "INHERITS" more than one class.

So, unfortunately, I will just have to tear apart my beautiful interface structure, and re-implement "super interface" methods in the "sub-interface" without inheritance.













I guess this isn't the end of the world for a feature like this.  However, I stand by my Garbage Collection statement; a feature like that should have been implemented when the first OOABL version was released or the release should have been held off.  The problem is now if you want to support

Posted by abevoelker on 19-Nov-2010 09:25

Of course, this code will return FALSE for TYPE-OF(myObj, "bar") where interface inheritance is not supported, and TRUE where it is (i.e. OpenEdge 11 and up).  So, there actually are advantages to having interface inheritance support in sufficiently complex designs (real-life example: java.util.Collection interface extends java.lang.Iterable).

Maybe Progress will solve all these issues by taking my suggestion and letting us run Java or other JVM languages in-line with our OpenEdge ABL programs... it should be possible, assuming the OpenEdge AVM runs on top of the JVM in all cases (I think it does now?  Maybe an OE expert can clarify).  But that is getting a little off-topic.

Posted by Thomas Mercer-Hursh on 19-Nov-2010 11:26

I know there are people who think otherwise, but personally, I think garbage collection is for people who aren't careful.  I'd rather manage lifecycles more consciously.

Perhaps it would help if you laid out what you were trying to accomplish here specifically.  There are probably at least three possibilities:

1. You have encountered a genuine gotcha where the design you propose is the best design and you will have to wait a year to implement it and workaround in some fashion in the meantime;

2. There is another way of thinking of the problem which accomplishes the purpose as well or better and which can be implemented now; or

3. Someone will decide that the proposed model is flawed and offer another solution which either does or does not require interface inheritance, but which at least corrects the flaw.

Sometimes, when one gets stuck not being about to do something because of a language limitation one can get stuck thinking that the proposed solution is the only approach so that stepping back from the problem for a fresh look is a good idea.

Posted by Thomas Mercer-Hursh on 19-Nov-2010 11:30

The AVM does not run on top of the JVM.  It will run alongside the CLR in 10.2A+ and communicate across a bridge, albeit with some compromises due to the fact the AVM is single-threaded and the CLR is not.

For side by side communication with a JVM you might want to check out

But, my only temptation in that direction relates to multi-threading and, if that is important enough, it isn't clear why one would stick with ABL.

Posted by abevoelker on 19-Nov-2010 12:43

Interesting!  Thanks so much for explaining that.  By CLR, I assume you mean the Microsoft .NET Common Language Runtime?

Also, does the AVM do any type of interaction with the JVM?  I ask because I've heard our admins say that Java is required to be installed to run the new OpenEdges as well as that they've "seen some Java errors when things really mess up".  But they might just be confused.  I've also seen some funky Java ANTLR errors on my source code editor at work, so I assumed that a Java version of ANTLR was being used to compile ABL into bytecode.  So those reasons are why I made that assumptions.  But you know what they say about assumptions.

I will check out that project you mentioned - looks very interesting.  However, I do most of my programming in Linux at home, so at first glance I don't think I can make much use of it as it requires a .NET .dll file.

Posted by abevoelker on 19-Nov-2010 12:55

Thanks for the input!  I totally agree about explaining the the issue more thoroughly, in order to uncover what in Perl-land is called an "XY problem".  In my case it is more of just dabbling with the OOABL features, so nothing totally concrete to be solved.

I will agree to disagree about the garbage collection... I think it goes against the nature of that simplicity implied in the "4GL" buzzword.  Also, when I hear "no GC" I think that the programmer should have more fine-grained memory control of objects, like in C++ where I can allocate n bytes, and choose either the stack or the heap.  I can also see the exact size of an object using the sizeof function.  In Java you only put your objects on the heap, and it is difficult to gauge the size of an object without memory profiling.  The upside in Java is you don't really have to concern yourself with object size as you aren't doing the memory allocation / deallocation yourself.  Also, primitives like int and char do have defined byte sizes, you can make a rough guess (I don't think ABL has very 'primitive' primitives... I mean just how big is a CHARACTER anyway?  Isn't it variable?  There isn't really a char equivalent).

To me, OOABL combines the worst of both worlds in pre 10.2A releases.

Posted by Thomas Mercer-Hursh on 19-Nov-2010 12:58

The Progress product line does use Java in various places, particularly in some database functions and in OpenEdge Architect.  The latter is particularly interesting since, if one is doing the ABL GUI for .NET then one has a JVM, AVM, and CLR all running at the same time!  But, at runtime, there is no Java involved in the AVM itself.  Only in some of the DB utilities.  OEA is all Java, of course, so three are utilities like the code tree which are parsing the ABL code using Java and ANTLR, but the actual compilation to R-code is not done by Java.

The jpjvm is open source so I am sure it is adaptable.  John is pretty busy these days, but ask questions on OE Hive.  But, I would start with laying out why you want to use it.  There don't tend to be a lot of good reasons.  There are some places where this kind of synergy makes sense.  Propares, for example, is written in Java but compiled with a tool to C# and then used by the APL ProLint for rapid parsing of ABL code.

Posted by Peter Judge on 19-Nov-2010 13:10

has a JVM, AVM, and CLR all running at the same time! But, at runtime, there

is no Java involved in the AVM itself. Only in some of the DB utilities.

My understanding is that the AppServer is heavily (largely?) Java-based. That's a fairly significant runtime piece of an app :).

-- peter

Posted by Thomas Mercer-Hursh on 19-Nov-2010 13:18

Perhaps, but the distinction I was trying to make is that it was not involved in the AVM or in the execution of ABL code.

Posted by Thomas Mercer-Hursh on 19-Nov-2010 13:33

Well, if you have some concrete issue you want to solve, bring it back here.  I had some quite entertaining and enlightening conversations exploring how to deal with the lack of interface inheritance in designing a set of collection classes ( ).  The end result was much simpler than the original.

I suppose that I see the purpose of ABL is not to make things easy ... since only trivial things are genuinely easy ... but to make the developer more productive in producing high quality solutions.  I don't think one writes high quality solutions without a consciousness about lifecycle so when one knows that one is done, one might as well get rid of it without creating the overhead of needing a behind the scenes indirect tool to get rid of it for you.  Maybe.  That seems like the path toward lingering references and thus memory problems as well as just failing to think clearly about lifecycles.  Bit old fashioned of me, I suppose, but that is my inclination.

Posted by Admin on 21-Nov-2010 00:32

I really wish Progress would have implemented a more complete OO implementation instead of all of this incremental stuff. 

I'm glad they didn't wait. That incremental approach worked fine with me. Noone would have OO in the ABL today if PSC would have waited with their release until they have interface inheritance, collections, serialitzation, ...

The lack of interface inheritance is hurting me a lot too. In our frameworks this causes a lot CASE and (TYPE-OF or TYPE-OF) where it wouldn't be required with interface inheritance. But still we get the job done.

Posted by Admin on 21-Nov-2010 00:33

abevoelker schrieb:

That sounds perfect, but I'm on 10.2A so there are no abstract classes! 

What's the problem with upgrading? When you're on maintenance, that just a telefax away.

Posted by Admin on 21-Nov-2010 00:37

When you need interface inheritance just on the 10.2A or 10.2B Windows GUI client, not on the AppServer, not on character client, you may - as a temporary fix until OE 11 is available - use .NET Interfaces.

ABL classes can implement .NET Interfaces and they support inheritance.

Just create an assembly file (.NET 3.0 or .NET 3.5) containing the interface types only and add that as a referenced assembly ot your OpenEdge architect project.

Legally you should be on 10.2B02 for this. As prior to that release the usage of the GUI for .NET bridge was officially restricted to the creation of appealing user interfaces (

Posted by abevoelker on 21-Nov-2010 08:32

$.  I'm not a rich guy - I have a young daughter, my wife is flying all over  the place right now doing medical school interviews, and we are currently living in a  place where programmers do not get paid very much.  So there is no way  that I will be paying Progress anything out-of-pocket just to sustain a  little bit of hobby programming.

I have 10.2A at home because I downloaded an evaluation version of OpenEdge Architect like 6 months ago or so.  I have downloaded a 10.2B OEA 60-day trial, but it keeps erroring out on me on my Windows partition (haven't tried the Linux install).  It might be because I have a pre-existing Eclipse install; not sure.

At work, we are on 10.1C.  There has been "talk" of potentially upgrading, but I'm the only person that does OO (and I actually have to fight my coworkers to even use OO so it's kind of a hot button issue), and there doesn't appear to be a whole lot of big advantages that I can sell to management to upgrade to 10.2A or 10.2B that are non-OO related.

Posted by abevoelker on 21-Nov-2010 08:35

Thanks for the idea!  Unfortunately for me, since we have a strong Unix base, I will not be able to take advantage of the ability to run .NET code from ABL.  It is a really cool feature that you can do that though.  It would have been cooler if they chose an OS-agnostic language like Java or something, though (I know it was originally created to make pretty screens and the unrestricted bridge was more of an afterthought from user demand).

Posted by Admin on 21-Nov-2010 08:45

But I've seen an appealing Java UI...

Posted by Thomas Mercer-Hursh on 21-Nov-2010 11:48

But, at work they are on maintenance?  If so, you shouldn't need some big incentive to keep on current versions.  You should just do it because it is easy to do and then you are on the supported release, the one which is getting attention and fixes.  And, chances are, once there you will find things of value which weren't necessarily obvious looking at just the big items.

Posted by gus on 22-Nov-2010 09:56

The AppServer broker is written in Java. The agents are 4GL runtime, variants of _progres, written in C with some C++ but no Java.

Posted by abevoelker on 01-Dec-2010 09:54

Thanks for the authoritative response to this inquiry.  In light of this fact, I withdraw my "in-line Java" idea and rescind the Progress Enhancement Request that pertains to it (#4100 on the ERS).

This thread is closed