SubInterfaces (OOABL)

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

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.

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!

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.

&GLOBAL-DEFINE INTERFACE_INHERITANCE_SUPPORTED INTEGER(SUBSTRING(PROVERSION,1,2)) GE 11

INTERFACE foo:

  METHOD PUBLIC INTEGER foo().

END INTERFACE.

&IF {&INTERFACE_INHERITANCE_SUPPORTED} &THEN

INTERFACE bar INHERITS foo:

&ELSE

INTERFACE bar:

  METHOD PUBLIC INTEGER foo().

&ENDIF

  METHOD PUBLIC INTEGER bar().

END INTERFACE.

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.

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 http://www.oehive.org/project/jpjvm

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.

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.

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.

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 ( http://www.oehive.org/CollectionClassesForOORelationships ).  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.

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.

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.

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 (http://blog.consultingwerk.de/consultingwerkblog/2010/09/progress-relaxes-usage-restrictions-of-gui-for-net-bridge-with-10-2b-service-pack/).

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

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

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

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.

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

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