| Language level interfaces would be great, but they could also easily have the same problem Abstract supertypes currently have, of being poorly defined semantically, and hence being less useful than they could be. The main change needs to happen in the community, in terms of * more formal specifications for Abstract types your package defines --- including in the language itself; I understand there's recently efforts to define what an `AbstractString` is, exactly, and there needs to be a lot more of that * tests that test the limits of this specification by defining new types that are very different from existing ones, but conform to the specification (rather than the current usual practice of just testing with already existing types only) * More integration of things like OffsetArrays, DimensionalData, AxisArrays, etc. in test suites * An explicit "Scope and Limitations" page in package docs (like Revise.jl's Limitations page [1]) that mention what has been tested and what hasn't/isn't meant to be supported I'm sure there's many other low hanging fruits that the community could address by itself - it's pretty late here and these are what my brain could come up with right now. But I see this largely as a community best practices and culture problem, that language features can help with to some extent, but needs to be solved at the social level. [1] https://timholy.github.io/Revise.jl/stable/limitations/ |
[1] https://news.ycombinator.com/item?id=32747387