-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add InterfacesCore subpackage #39
Conversation
Not sure I understand the rationale here, can you elaborate? |
Ok. So I want to add Interfaces.jl to a package, without adding a full dependency on it or adding any overheads. Theyre not so bad, but I imagine people will want a no cost option initially. And if all the interface tests get really long it will have some small overhead. So the options to do that are:
Its kind of annoying to have to do 1 everywhere. But 2 doesn't actually work currently, because if you use the So we need to define the interface type in the main package, e.g. in DimensionalData.jl. So:
I guess this should be the package readme |
Is an 8-step procedure really worth the trouble of what is probably a very small package overhead? If Interfaces.jl is to be widely adopted it must be very simple, and that split makes it so much more complicated. |
Can we quantify the overhead somehow? |
Yeah, maybe not worth it its very little overhead. This is Interfaces.jl + DimensionalDataInterfacesExt.jl julia> using DimensionalData
julia> @time using Interfaces
0.004137 seconds (4.39 k allocations: 334.969 KiB) But didn't you put the Graphs.jl interface in a separate package? That's the problem I'm trying to solve. |
Two reasons for that
But I didn't have to put the checks in the same place as the definition. Ideally the definition should go in Graphs.jl and the checks in each implementing package, as God intended |
It just feels a bit weird putting the interface tests in runtime code with the rest of the package, and I'm guessing some people wont like that. But maybe its not an issue |
I think we'll cross that bridge if we get to it. What I like about your approach is that the design is dead simple, let's not overcomplicate it to gain 4 ms. If you really care about moving the tests out of runtime code, maybe there could be an extension of Interfaces.jl that depends on Test being loaded? |
Yes could be interesting to use For now I'll move the DimensionalData.jl interface to the package. |
And your right keeping it dead simple might be the most important thing here. Thanks for the feedback |
This PR adds an InterfacesCore.jl subpackage.
All it implements is
abstract type Interface end
and a@interface_type
macro.The reason for this is so we can define the interface type without any package overheads, and add Interfaces.jl as an extension. This means packages can just go
using Interfaces
and test their implementation, rather than needing to load another package.We cant use extensions currently because the type would be defined in the extension, and not be accessible to anyone.