FWD » Core Development » Base Language

3821c/11437 fixes the case of abstract extent properties (forgot to check them).

This seems to work on 4384h, at least for oo/Discovery/OpenEdge/Core/IObjectArrayHolder.cls.

Constantin, I have a conversion error when using one of the .NET classes ClientSocketConnectionParameters. There are two extent properties in that class and although I do see two getters (one for whole array, one for specific array item), two setters (again, whole array or specific item) and two extra methods one of type LENGTH and one RESIZE when we ran the conversion code that is checking the size of the property array is not using the corresponding LENGTH method but the getter returning the whole array :(

extent(obj:SslCiphers) -> obj.ref().getSslCiphers()

However, running the same conversion on a test we have for this oo/quirks/property_extent/test_property_extent_type.p is different (correct).

extent(obj:ExtentProperty) -> obj.ref().lengthOfExtentProperty()

One issue there with the converted code is that if we try to reset the property by setting the extent to null (?) we get this:

obj.ref().resizeExtentProperty(new unknown())

Marian, please post the 4GL code snippet which doesn't convert properly. Thanks!

Constantin Asofiei wrote:

Marian, please post the 4GL code snippet which doesn't convert properly. Thanks!

The code is in oo/openedge/net/server_connection/client_socket_connection_parameters/test_property_ssl_ciphers.p but basically it's this that doesn't convert right:

define variable oCSCP         as ClientSocketConnectionParameters no-undo.

define variable numExt        as integer                          no-undo.

oCSCP = new ClientSocketConnectionParameters() no-error.
numExt = extent(oCSCP:SslCiphers).

Constantin Asofiei wrote:

Marian, please use the attached patch. I still need to reconvert some apps before deciding that's OK for 3821c.

Constantin, did applied the patch and did a gradle ant-all in goldencode followed by ant deploy.all in testcases project. When running conversion it looks like it's still using the getter instead of length when calling extent on that property, some step I've forgot about maybe?

And I don't know what is causing the property indeterminate array to be removed from the dynamic list, right now whenever we try to set it's value it throws error because the extent is not seen as being uninitialized (isDynamicArray returns false).

Now, the TypeFactory.characterExtent register the array as dynamic but pending, at some point I can however see the arrays are moved into the dynamic stack but there is a place where those are being 'unregistered' and haven't yet found it... something extra that need to be done for indeterminate array properties after your changes introducing 'pending' registration?

Marian, the patch fixes the example you posted, with sslCiphers, and I've checked other cases and it works. Maybe the patch was not applied fully?

Please let me know an example for the runtime issue with dynamic extent.

Constantin Asofiei wrote:

Marian, the patch fixes the example you posted, with sslCiphers, and I've checked other cases and it works. Maybe the patch was not applied fully?

Please let me know an example for the runtime issue with dynamic extent.

Of course the patch was not applied, the project name do not match so just hitting next without looking what actually happened didn't help... will give that a try in a bit.

Constantin Asofiei wrote:

Marian, the patch fixes the example you posted, with sslCiphers, and I've checked other cases and it works. Maybe the patch was not applied fully?

Please let me know an example for the runtime issue with dynamic extent.

Constantin, with the patch applied the conversion does use the 'lengthOf' method instead of the getter as it was before. Thanks for that.

Constantin Asofiei wrote:

Marian, the patch fixes the example you posted, with sslCiphers, and I've checked other cases and it works. Maybe the patch was not applied fully?

Please let me know an example for the runtime issue with dynamic extent.

It was failing for all tests where the class being tested had an indeterminate extent property, found out for handle the array was not registered as dynamic when initialized (TypeFactory.handleExtent), then for objects the registration was made without the extra flag you've added for pending (default to true) so the array property was left as not being dynamic at the end. Changing the call to registerDynamicArray to pass the second parameter set as false solved the issue for object data type. Last thing I've changed the call to registerDynamicArray in initExtent to do the same thing and now I get the expected behavior for character data type extents as well.

A test is in oo/openedge/net/server_connection/client_socket_connection_parameters/test_property_ssl_ciphers.p.

Marian Edu wrote:

A test is in oo/openedge/net/server_connection/client_socket_connection_parameters/test_property_ssl_ciphers.p.

Thanks for this. The issue is with persistent programs (which legacy OO instances are) - the dynamic extent (and other) info must be kept for each persistent program, and 'pushed' on the stack when something in that persistent program is called. I'll work on fixing it.

BTW, please revert your changes made related to #4824-17.

Constantin Asofiei wrote:

Marian, see the attached patch for the #4824-17 issue. Now the test passes.

I can't apply the patch as-is, even if I remove the changes for TextOps and ClientSocketConnectionParameters it still can't find the patch segment for ObjectOps so I will try to do it manually.

I've also fixed some enum issues.

Yeah, we did the same for substitute on our branch so guess this is a conflict that will have to be resolved at some point :)

Constantin Asofiei wrote:

BTW, please revert your changes made related to #4824-17.

You probably mean removing the second parameter to registerDynamicArray, pretty sure this has to be called for when an extent handle/object are created with size 0.

Constantin Asofiei wrote:

Marian, see the attached patch for the #4824-17 issue. Now the test passes.

OK, applied the changes on ArrayAssigner and ObjectOps (no idea why Eclipse didn't find the patch segment as it was right at that line). The test now passes without using the second parameter for registerDynamicArray on initExtent.

The patches from #4824-19 and #4824-12 are in 3821c rev 12170.

Constantin, I see this is closed already but one issue we still see with conversion is when unknown (?) is used to set the size of an extent property (resize).

You can see that in oo/quirks/property_extent/test_property_extent_type.p.

extent(extentProperty) = ?.

translates to

obj.ref().resizeExtentProperty(new unknown()).

That comes from literals.rules but the 'classname' note there is null when property's resize method is being called while for other regular OO methods the class name is correctly set to the method's parameter data type.

Argh, was beating around the wrong bush... the fix come by adding the 'int64' annotation when the method is rewritten in oo_references.rules (#781):

<action>childref.putAnnotation("classname", "int64")</action>