You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Merge pull request #95 from woodwan/woodwan/TolerateMissingMethods
## Description
Suppose two components collaborate by passing abstract class instances between one another. The definition of the abstract class interface against which the two components were built must be exactly the same.
For example, suppose we add a new method to an interface and regenerate one of the components, but not the other.
If we pass an implementation of this interface from the component _without_ knowledge of the new method to the component _with_ knowledge of the new method, the generated ACT code in the newly-generated component will throw an error at the point where the object is passed over because an expected method is missing.
It's desirable to have a little more leeway here, since during development of collaborating components it is often the case that they will go temporarily 'out of sync ' - e.g. testing a development build against a prebuilt version of a collaborator.
I've address this in the generated C++ binding here by throwing an error at the point of calling a missing abstract method, not at the point where loading it fails.
## Verification
Created two 'concrete' components, a shared 'base' component definition containing an abstract class, and a executable consuming them.
One component produces an instance of the interface, the other consumes it. The executable 'wires' them together. Generated, built and verified that this worked.
Modified the interface to add a new method. Regenerated the 'consumer' component (so it should expect the new method, which won't be present.) When the consumer is regenerated _without_ these changes, it throws up an error. When the consumer is generated _with_ these changes, it works, since it does not attempt to call the new method.
0 commit comments