Generics - Forum - OpenEdge Development - Progress Community
 Forum

Generics

  • Hello,

    does anyone know if Generics are officially planned for OE11.0?

    Thanks,

    Jan

  • does anyone know if Generics are officially planned for OE11.0?

     

    I don't know the answer to your question.

    But right now we use include files in a class as a workaround to the lack of Generics.

    CLASS ListOfTypeX:

    { Consultingwerk\List.i TypeX}

    END CLASS .

    In the include file we implement the required methods and properties using the include file parameter whenever we need the variable type.

    Works for us as typically we only need a limited amount of generic types in an application.

  • It's a nice suggestion, but that's probably just a workaround within ABL, the reason I 'need' generics is I would like to use a .NET assembly who's API uses generics. I think I need to write a wrapper in .NET that hides the generics for using this API in 10.2B.

  • It's a nice suggestion, but that's probably just a workaround within ABL, the reason I 'need' generics is I would like to use a .NET assembly who's API uses generics. I think I need to write a wrapper in .NET that hides the generics for using this API in 10.2B.

    You can define .NET generics from the ABL since 10.2B. You should be able to define a generic type with T being a .NET Interface and an ABL class implementing that interface as the members.

    Does that help? Or do you need an ABL generic class? For achieving .NET visibility of that type you'll need a class inheriting System.Object anyway.

  • It might, I didn't know that, I'll have to try.

  • In 10.2B you can 1) implement a .NET interface that uses Generics and 2) instantiate a .NET Generic type using a .NET type for the Generic. For example List could be defined in ABL as List. You can run methods on the instantiated class since the Generics part of it is resolved by the definition.

    What you cannot do is run a method that is explicitly defined as taking its own type (separate from its containing type). At this time this capability is not being considered for 11.0.

    -Shelley

  • Crushing my hopes yet again ... even though, of course, it wasn't really news.

    At the NorCal PUG meeting last week someone suggested that the motivation PSC had for supporting OO was entirely based on their interest in ABL GUI for .NET, which is certainly more natural in OO and there are some features which really only map on to OO constructs.  I'm not that cynical, but there certainly are places where one feels that support for AG4.N has an overly dominant role in deciding which missing parts to implement next. I'm very grateful for the many extensions to the OO support that have been added since 10.1A ... there is a whole lot of my original wish list that has been added to the product ... but I also have to say that it is time for another big chunk and a chunk which has to do more with establishing parity between OOABL and other mature OO languages.  I'm tired of having to make apologies and explanations and spins.  Generics ... as dangerous and misused as they can be in much code are really very important for creating frameworks.  How can we expect OO to get serious in the ABL world if we leave barriers to good frameworks?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Support for .NET generics, as Mike says, is there ... what we don't have is ABL generics.  As Mike says, you can "fake" the ABL side ... where "fake" means avoid the stupid duplication of nearly identical ABL code differing only in type.  You can see this illustrated also in my old collection and map class code at http://www.oehive.org/CollectionClasses .  But, gosh it is ugly.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Thanks Shelley, now that I see the syntax I remember testing this in the past, I must have somehow  forgotten it.

  • I'm relatively new to the Progress/OpenEdge scene, but I am very glad that Progress corp. at least added some support for object orientation in OpenEdge.  It's probably what kept me from jumping off of a tall building after getting this job straight out of university.

    That said, I don't think OpenEdge will ever get to be as serious/competent with OO as other languages currently are.  There's just too much legacy baggage/backwards compatibility required for a language that was designed to be a top-down procedural language from the start.  The other languages have the advantage of being designed as OO from the get-go.  Progress/4GLs were an interesting idea in the 80's/early 90's, but let's face it - the 4GL concept lost out to better ideas (i.e. OO).

    The snail's pace that a product like OpenEdge takes in small, incremental improvements (i.e. copying what other products have already had for quite some time) is not nearly fast enough anymore.  Try comparing the latest OpenEdge to a modern solution like Ruby + MongoDB (a document-oriented, schema-less database).  It's like comparing a horse and buggy to a Bugatti Veyron.  These agile programming languages are the real 4GLs, so it is nice that Progress took that tag off of their programming language name.

    The only solution I see is to completely migrate to a newer language and platform.  Otherwise, you will be waiting until OpenEdge 14 for a solid OO platform (except it will probably not be "OpenEdge" anymore, it will have been renamed a couple times by then).  And by that time, OO will be old news (well, at least the Java clone that Progress will surely have created, that is).  If you wait around to migrate, you risk Progress corp. getting wise to the concept and really locking down the platform, like removing or deprecating JDBC drivers.  Oh wait... didn't that already happen?

  • You might enjoy reading this

    Java Is A Dead-End For Enterprise App Development : http://goo.gl/Kpddv

  • I actually already have several weeks ago; read the comments section.  Might I counter with this (did I say Java was the solution)?  Ignoring the fact that the article is a total puff piece, I do agree with the shill's author's general sentiment that Java is not the perfect solution and is probably overused in industry.

    However, if I had to choose only one language to use and it was strictly between Java and OpenEdge, I would take Java any day.  It has a real language specification, actual primitive datatypes, better OO support (including garbage collection from the start), portable code (import statement isn't brittle like USING is), not tightly coupled to a single (shoddy) datastore, interacts with other JVM languages at the bytecode layer (JRuby, Groovy, Scala...), widely used means tons of libraries available (including basics like Collections), and on and on and on...

    The bottom line is just getting away from OpenEdge and getting onto any modern platform with an open spec is the ideal solution, because you will no longer be stuck in the single-solution, vendor lock-in that is OpenEdge.

  • If you don't want to work in OpenEdge .... don't.   But, don't bother trying to convince us that are perfectly happy working in OpeneEdge that we are wrong to want to do so.  Just no point.  So, let us get on with arguing in favor of making it better.  It does keep getting better, you know, significant so.  How many of the databases you would like us to use support transparent data encyption ... and do so with anything like the efficiency OpenEdge does.  How many have or plan to release multi-tenancy next year?  How many include products like Savvion, Sonic, Apama, etc., etc. in their product mix ... with cmmon IDE too!  OpenEdge is for real, serious applications, not toys.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • tamhas wrote:

    How many have or plan to release multi-tenancy next year?  How many include products like Savvion, Sonic, Apama, etc., etc. in their product mix ... with cmmon IDE too!  OpenEdge is for real, serious applications, not toys.

    Sorry Thomas, but aren't Savvion, Sonic and Apama products that were available for Java before they were avaialble for OE? The IDE is also just Eclipse with some OE ABL tools added to them and if you've ever coded java in eclipse you will be aware that the java tools for eclipse are significantly better than the ABL tools. I also think the need for multitenancy in SQL databases is not even close to that in progress, because at least in MySQL you can just CREATE DATABASE... ; and upload the schema and all without much effort...

    If you want to boost about OE strengths there's one very big one:

    We've got over 7.000.000 lines of custom code, some of it is 18 years old, some of it is brand new. We've had to rewrite almost no code in all these years just because of an upgrade. If something works it just keeps working, yet when writing new code or even making changes/improvements to existing code we can use all the new possibility's we want.

    I really would like the ABL to keep up with other languages progress (far far better OO and tools support, opensource libraries available, the ability to change schema online while everyone continues to work (that requires some care off course not to break applications but is often possible with SQL),...) but I would not want to have to rewrite all my code every five years to do so. While most Java code hasn't needed rewriting when new versions came about (like some other unnamed languages ;-)), but it hasn't been around for 18 years either and JRuby certainly hasn't been.

  • Trust me, I don't plan on working in it forever; I'm currently geographically restricted.  However, my wife is deciding on a medical school right now and then we're outta here.  Should be less than 6 months left now.

    You're right that this probably isn't the place to open this can of worms.  I just think that it is interesting that OE continues to push towards the cloud (e.g. that multitenancy you mentioned) instead of making the base language more dynamic.  I guess it piqued my rage for reasons I won't expound upon for fear of prolonging the discussion.

    If you're happy to work in OE... then by all means continue.  I'll just post a link to the Ruby DataMapper adapter I'm writing when I finish it, for those who are interested.  I know my employer is.