SubInterfaces (OOABL) - Forum - OpenEdge General - Progress Community

SubInterfaces (OOABL)

  • 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.

  • 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.
  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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!

  • 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!

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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.


    INTERFACE foo:






    INTERFACE bar:





    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

  • 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.

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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.

  • 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.

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice

  • 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.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice