Feature #9868
Support generics introduced in Progress 12.x
0%
Related issues
History
#1 Updated by Ioana-Cristina Prioteasa over 1 year ago
- Related to Feature #9488: implement all built-in OO classes using the open source ADE code from 12.8.4 added
#2 Updated by Ioana-Cristina Prioteasa over 1 year ago
- File MultipleImplements.cls added
- File TestMultipleImplements.cls added
Progress 12.x introduced built-in classes that use generics, such as Progress.Collections.HashMap and Progress.Collections.List.
- Declaring variables with generics:
def private serializable var mBackingList as Progress.Collections.IList<Object>.var private HashMap<ILongcharHolder, Object> mBackingHashMap.
- Instantiating generic objects:
this-object(new Progress.Collections.List<Object>()).constructor private List (input pBackingList as Progress.Collections.IList<Object>):
- Navigating generic structures:
var Progress.Collections.IIterator<KeyValuePair<ILongcharHolder, Object>> iter. assign hValue = iter:Current:Value.
Here,Valueis a property fromKeyValuePair.
Additional considerations:
- A class can implement the same interface multiple times with different type parameters:
CLASS MultipleImplements IMPLEMENTS IComparable<OpenEdge.Core.Integer>, IComparable<OpenEdge.Core.Decimal>:
Here the class needs to contain 2compareTomethods:METHOD PUBLIC INTEGER CompareTo(other AS OpenEdge.Core.Integer):METHOD PUBLIC INTEGER CompareTo(other AS OpenEdge.Core.Decimal):
I attached the completedMultipleImplements.clsandTestMultipleImplements.cls- an unit test on this matter.
- Instantiating a generic class without type parameters is invalid syntax in Progress 12. This is not permitted:
myList = NEW List().
#3 Updated by Greg Shah over 1 year ago
For convenience, I'm reproducing my post from #9488-131:
Greg: considering that the #9457 project doesn't use generics in the app code, I want to find a way to delay this implementation. One of the 'weird' parts is:
[...]Note how you can implement the same interface but with different generic types. This is not allowed in Java.
Yuck. Some things to record for posterity:
- OO 4GL currently (as of the latest 12.8 LTS) doesn't have generics support that can be used by end user code. These references are only in the built-ins. Presumeably, they implement this limited special support in the native code of the OE runtime.
- OE is shrinking (dying actually) annually and the next LTS release is not expected until at least 2027 (best case) as explained by Progress Software Corp's (PSC) themselves. Most (all?) commercial ISVs would never deploy an OE release that is not LTS. That means that no one will be deploying the post-12.8 LTS until 2027 or possibly long after that.
- Supposedly PSC is working on generics for OO 4GL but generics can't appear in real OO 4GL code that goes to customers until that next LTS release is available so we have years to go before end user code will ever have direct access to generics.
- I wonder if OE will still exist in 2028 or if it will just be in maintenance mode. Actually, it is already kind of in maintenance mode since the amount of development on OE itself is very limited. But for the sake of argument, let's say that maintenance mode is in the future somewhere. My suggestion is that given the pace of decline, maintenance mode is possibly not that far in the future. Under those conditions we may never have to implement generics in the FWD implementation of the OO 4GL.
- Nevertheless, the current approach chosen by PSC seems to match the C# concept of generics which uses runtime information and tends to be much slower than generics in Java which use type erasure and are fast but have more type limitations on the implementation. As you note, we can't directly implement two parameterized interfaces using Java generics because of the type erasure implementation.
If it is feasible to defer the work on generics to another task, I am OK with that so long as that work can be deferred to after the current projects are complete. My point here is that if we defer the work but then just have to work it again in order to finish some current projects, then the deferral doesn't help too much. So, I'd like to know if we need it in the short term or not. If not, then we should defer it.
#4 Updated by Greg Shah over 1 year ago
I'm guessing that there is no syntax in the built-in classes which shows how to define a parameterized type (e.g. T like in a Java definition public class MyGenericisedClazz<T> { /* references to type T */ }). Is that correct?
In other words, they have some sytnax to reference existing classes that implement generics but not to define them in a class.