Rclone has backends which connect to cloud providers. These all implement a common interface. So far so good.
However some cloud providers can implement optional features, say a server side copy of an object.
Rclone used to use interface upgrades to discover these. Still so far so good.
However rclone has backends which wrap other backends, for example the crypt backend which encrypts file names and data.
This backend has to implement all the optional features - you want to be able to server side copy an encrypted file if possible.
The problem comes when the crypt backend wraps another backend which does not support server side copy.
What rclone used to do here is return a special not implemented error. This works, but isn't ideal because you have to call the method to find out if it is supported and often you'd like to know before that.
I eventually gave up on interface upgrades and resorted to good old function pointers which you can check against nil. When the crypt backend starts up it finds out whether the backend it is wrapping supports server side copies and if not nils the pointer.
A little bit of reflection removed the boiler plate for this and it turned out quite neatly.
If instead there was a way for crypt to remove methods from its method set then that would be a better solution.
Rclone has backends which connect to cloud providers. These all implement a common interface. So far so good.
However some cloud providers can implement optional features, say a server side copy of an object.
Rclone used to use interface upgrades to discover these. Still so far so good.
However rclone has backends which wrap other backends, for example the crypt backend which encrypts file names and data.
This backend has to implement all the optional features - you want to be able to server side copy an encrypted file if possible.
The problem comes when the crypt backend wraps another backend which does not support server side copy.
What rclone used to do here is return a special not implemented error. This works, but isn't ideal because you have to call the method to find out if it is supported and often you'd like to know before that.
I eventually gave up on interface upgrades and resorted to good old function pointers which you can check against nil. When the crypt backend starts up it finds out whether the backend it is wrapping supports server side copies and if not nils the pointer.
A little bit of reflection removed the boiler plate for this and it turned out quite neatly.
If instead there was a way for crypt to remove methods from its method set then that would be a better solution.