Let’s say I have created a public library/package for use by anyone. In this library, I export a service like so.
package myLib
type LibService struct {
}
func (l LibService) GetThingName(id string) string {
... Some implementation ...
}
As a user of this library, I should define my own interfaces (as recommended here) to reduce coupling with the dependency, facilitate easier mocking for tests, etc.
import "codeplace.com/someone/myLib"
import "codeplace.com/someone/otherpackage"
package myProject
type ThingNameGetter interface {
GetThingName(id string) string
}
func MyProjectFunction(getter ThingNameGetter) string {
return getter.GetThingName("my id")
}
Now, after some time, the conceptual domain of the library changes in such a way that the GetThingName function is no longer sufficient. I would love to make the change below and have all of my library consumers know about the deprecation.
// Deprecated: Use GetNamespacedThingName
// This function will start panicking on Dec 1, 20XX
func (l LibService) GetThingName(id string) string {
... Some implementation ...
}
func (l LibService) GetNamespacedThingName(
namespace string, id string,
) string {
... Some implementation ...
}
The problem is: because myProject has defined its own interfaces, they will not see the deprecation warning highlighted in their IDE (I don’t think lint will catch it either).
So they will not have time to react to the upcoming function removal. Instead, it will just suddenly “happen” on Dec 1, 20XX and they will have to scramble to update their usages.
What is the correct way to approach deprecation when consumers define their own interfaces?