Well, this kinda depends on how they work, I am not sure how you would get errors before runtime as, in Julia, compile and runtime are interleaved, and there is not a global static check before the code starts running.
I am also kinda skeptical that projects that do not document informal interfaces will adopt formal interfaces. A poorly documented project will probably be the same that will not adopt formal interfaces, or that will adopt them in such a negligent way that will just create new problems.
Unless formal interfaces do bring some benefit for the compiler, I do not see a reason to implement them, they do not replace the need for documentation.
Formal specifications to “define” interfaces are an illusion: at most they capture methods and types, but do not really handle what the interface is supposed to do. Unit tests are much better for that.
I think the best practical way to deal with this in Julia as is is for packages that define an interface to expose (but not export) a ThatPackage.test_something_interface(...) function, possibly in a related mini-package for larger projects. Then everyone implementing and interface can just call this in unit tests and be done with it.
DataFrames for example is very hard to extent without reading lost of code. The interface if very poorly documented. Don’t get me wrong DataFrames is great but for something that is widely used the package it is very poorly organized. Extending for the average user is difficult.
Any way I don’t want to go down a rabbit hole @Tamas_Papp 's point is well taken. Just an example of something I ran into.
I think there may be a misunderstanding here — AFAICT DataFrames.jl does not define a generic interface distinct from the package per se. So if you are extending it, you are of course dealing with internals.
That said, it implements the excellent
interface which is well-documented (probably the most exhaustively documented interface outside Base).
Yes the I agree the user interface is well documented. My point is that formal interfaces make it easy modularization the internal code ( other devs being the users) and let other devs work with your portion mostly concentrating on his or her own piece. This is how my group operate using C#. The added benefit here is when some wants to extend it even if the internals are not documented there are clear interfaces between independent pieces of code. In Julia you would need to come with a standard with your group for doing since there is no way to have a formal interface. The flexibly of multiple dispatch is awesome but it can easily messy and disorganized. There are pluses an minus to both approaches. I like both languages. I just prefer to have the interfaces clearly defined rather than scatter around such in the above. Any way
I am wondering if you have tried it in practice though, or you are just assuming this.
In particular, just documenting your interface, and providing a test suite.
If you tried it, please tell us how you found it to be “messy and disorganized”, because I would find it really surprising. In particular, I cannot imagine anything more disciplined than incorporating interface tests in CI and getting red flags whenever they fail.
this is true, except they do have an abstract dataframe type, but it’s not “used properly” (i.e. there are too many functions defined only for dataframe