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
What is the best way to design the AXL API w.r.t. getting the transfer type from the caller.
Currently we take a string and AXL does the conversion axl_xfer_t type.
Should we change this so that AXL Create takes in an axl_xfer_t parameter instead?
Pro:
simpler api
the enum provides the set of xfer options
matches how other tools work
Cons:
as the API develops, the enum will change, possibly making incompatibility issues. We could avoid this by only appending to the enum, but this may lead to a bunch of cruft for xfer types that are no longer supported. Otherwise, users will have to recompile for what would be ABI compatible versions.
The text was updated successfully, but these errors were encountered:
Changing the enum would thus be a new major version in AXL... which will be true. It represents either new technology support or deprecation.
No user should try to use a new version of a library without recompiling. Some people do this, but that's wrong.
a typo in a string is a runtime error and a typo in an enum is a compile time error.
We can maintain the gap in an enum if we delete an entry (by manually specifying the gap) so there will not be a recompiling issue for those who are wrong and want to swap in libraries without recompiling.
What is the best way to design the AXL API w.r.t. getting the transfer type from the caller.
Currently we take a string and AXL does the conversion
axl_xfer_t
type.Should we change this so that AXL Create takes in an axl_xfer_t parameter instead?
Pro:
Cons:
The text was updated successfully, but these errors were encountered: