Suggestion: Add Alias types to OpconCommonDef

[MarvinW]

Hello,

There are several alias types that would be very useful to have (for the sake of code clarity), but currently they are not available in a central library. I'm thinking that OpconBaseCommonDef is the best place for these. Currently it only has SIZE_T and EVENTADDLTEXT_T, which are really generally useful. And maybe sometimes OOID_T.

I suggest adding these:

• BinIoIndex_T: used whenever a IDX_ variable of BinIo is expected, e.g. when passing them around in ParCfg
• EventHandle_T: used for return value of SetEvent etc. and as input for ClearEvent
• RetValState_T: used whenever a function/method returns a value that is meant to be assigned to _retVal directly, so can be OK, RUNNING, JUMP1-9 and any negative value in case of error (method should still describe which of these it uses)
• AsyncState_T: used as return value of functions/methods that should be called continously and report the status of execution, so can be 0 (OK), 1 (RUNNING) or any negative value to indicate error

Here are some more, but I am feeling much less strongly about those:

• EventNumber_T: For all event numbers
• InstanceId_T: For object instance IDs
• Command_T, Mode_T: For every place where you need to handle a Cmd or Mode enum

All changes would be perfectly backwards-compatible but enhance future programs, because we can use these types to annotate our variables and method parameters.

What do you think about this proposal? Any other types that would be useful?

[MarvinW]

I would kindly like to ask for feedback whether there is any chance that this idea will be implemented. Because if not then I want to add it to our BMG internal base objects.

[nexidator · Accepted solution]

Sorry for the late reply! We have discussed this matter extensively and come to the conclusion that we will not provide these alias types.

This does not mean that we don't feel they are useful in some places. But it doesn't feel right to provide the type definitions without using them consistently in our own libraries. Updating all objects to use the alias types would be too much effort for just a small readability improvement. Moreover, updating libraries to use the new types would be an incompatible change because it requires a higher minimum version of the base object, which means even more versioning effort.

[MarvinW]

Thanks for the response. I will go ahead and add it to our own framework extensions then.

If you think it's generally a good idea, maybe you can keep it as a note for Nexeed V3 or whatever comes next 😉