Remove duplicated variable "currentGear" from Interface.TransmissionControlBus about vehicleinterfaces

[dietmarw]

@tobolar I've added you to the "vehicleinterfaces-write" team so you should now be able to reopen this if you still think it necessary.

[harmanpa]

Fixed by #22

[tobolar]

Not able to reopen this issue but I don't believe the commit 071c9a0 really solves it. See also my comments in #22.

[harmanpa]

@tobolar

The reason to temporarily leave currentGear in VehicleInterfaces.Interfaces.TransmissionControlBus is only the backward compatibility, and it should be resolved in the next major version

It needs to be left in either TransmissionControlBus or StandardControlBus, and yes the choice to leave in TransmissionControlBus was to maintain backwards-compatibility.

However if we make a change for a major-version (which I think with the other open tickets we do need) we still need a migration-script. If we remove it from TransmissionControlBus then I'm not sure what the migration-script would say, unless we just remove TransmissionControlBus and use the migration-script to change dependencies to use StandardControlBus instead?

[tobolar]

If we remove it from TransmissionControlBus then I'm not sure what the migration-script would say

Is it absolutly necessary to cover all possible cases with a conversion script? Or is it acceptable if the forward compatibility is broken?

unless we just remove TransmissionControlBus and use the migration-script to change dependencies to use StandardControlBus

If this is a feasible way (except removing TransmissionControlBus) then we should do it.

To me, the question is not how the conversion should look like but what is the proper control bus definition and usage.
Proper way followed for all buses is to collect signals in StandardBus and StandardControlBus of a particular assembly (engine, transmission, etc.). Faulty way is to define signals somewhere in
VehicleInterfaces.Interfaces.

Do we really want to go that wrong way?

BTW there is followed an approach with replaceable bus instances in models. Therefore, bus connectors from VehicleInterfaces.<assembly>.Interfaces are always instantiated as replaceable in particular assembly models. To my knowledge, this was motivated due to some issues with Dymola years ago. But actually this contradicts the idea of expandable connectors. Moreover, it makes problems in more complex vehicle architectures because then all bus connectors of an assembly should be of the same definition. This means to replace a plenty of connectors for particular architecture.
The proper solution is to use "empty" bus connectors from VehicleInterfaces.Interfaces across the library as was the case in the early versions.

[harmanpa]

We have to cover changes with conversion scripts. I know parts of this library are quite poorly designed and there is a lot of learning since it was written, but it is heavily used. I have found cases in commercial libraries that are directly instantiating TransmissionControlBus and directly accessing currentGear. I myself have used VI as the basis of several libraries at previous employers of mine and I have no doubt there are similar things in those libraries.

Whether this is right or wrong, and whether or not the expandable-connector rules would deal with it, it remains the case that changes like this can break user-models. Equally I'd like people to upgrade else it's not worth us putting the effort in to improve things.

We could put currentGear back into StandardControlBus and add the following line to a conversion script (for v2.0.0):
convertClass("VehicleInterfaces.Interfaces.TransmissionControlBus", "VehicleInterfaces.Transmissions.Interfaces.StandardControlBus");
This would ensure that all direct uses of the bus are still valid.

[tobolar]

I understand.

but it is heavily used

:-(

Does it make any problems to leave the variable in both buses?

If we decide to go back to the idea of expandable connectors then such a conversion would not be necessary because then the buses from VehicleInterfaces.Interfaces will be instantiated instead.