FWD » Core Development » Base Language

There is this test which shows that extent arguments can be of different (but compatible) types:

class oo.ExtTest:
   def public property pch1 as longchar extent  get. set.

   method public void mext1(ch1 as char extent ).
      pch1 = ch1.
      mext2(ch1).
   end.

   method public void mext2(ch1 as longchar extent ).
      pch1 = ch1.
   end.

   constructor public ExtTest(ch1 as longchar extent ).
      pch1 = ch1.
   end.

   constructor public ExtTest(ch1 as char extent ).
      pch1 = ch1.
   end.

end.

In this case, we are calling mext2(character[]), while the definition is longchar[] - thus, as the argument is narrower than the parameter's type in 4GL, it is allowed.

In FWD, it tries to cast the array to the parameter'stype, like mext2(new longchar(ch1[0]));, but this is wrong - even without the cast, like mext2(ch1[0]);, it doesn't compile. We need either to invoke this as a dynamic call, or somehow prepare the arg to be compatible with the parameter's type. Also, we need to:

• check how functions behave in FWD, in the same scenario
• check other data types, like int vs int64
• check OUTPUT/INPUT-OUTPUT mode

Paul: please let me know if you've already found something similar.

Ioana: this is the scenario from #9488-147 for LongcharArrayHolder.

Constantin Asofiei wrote:

Paul: please let me know if you've already found something similar.

Yes, I noticed this behavior on #9877 to functions as well and it works even with custom made classes as well as with builtin classes like Progress.Lang.Object and Progress.Lang.Class . The problem on that task was about the output parameters and so this general behavior wasn't checked. In short, the solution was to override the getVariable() and setVariable() method taking into account the type declared from the function definition instead of the one from the DEFINE VARIABLE statement.

Paul Bodale wrote:

Constantin Asofiei wrote:

Paul: please let me know if you've already found something similar.

Yes, I noticed this behavior on #9877 to functions as well and it works even with custom made classes as well as with builtin classes like Progress.Lang.Object and Progress.Lang.Class . The problem on that task was about the output parameters and so this general behavior wasn't checked. In short, the solution was to override the getVariable() and setVariable() method taking into account the type declared from the function definition instead of the one from the DEFINE VARIABLE statement.

Thanks, this is lower priority than what you are working now.

For INPUT case, the solution (if arg and parameter type differs and is extent) would be to emit a <T extends BaseDataType> T[] BaseDataType.toArray(Class<T> parmType, BaseDataType[] ref), which would create a copy with the compatible type, and will be emitted instead of direct ref argument.

DYNAMIC-INVOKE/RUN/DYNAMIC-FUNCTION/NEW/DYNAMIC-NEW need also to be checked, if the runtime takes care of this automatically.

Also, we may need special toArray case for object type, as I assume you can pass a oo.Foo[] array argument to a progress.lang.object[] parameter.