-
Notifications
You must be signed in to change notification settings - Fork 93
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
Interface without needing AbstractGraph
?
#395
Comments
Ideally I'd love that, but it's even harder to test due to the notorious lack of interface specification in Julia. The AbstractGraph must have been introduced a decade ago or so, and at least it's a guarantee that you don't try to graphify anything and everything without being aware of it. Additionally, I haven't yet found a traits package that does everything I want and doesn't muddy the stack traces. For instance the use of SimpleTraits here causes problem with JET's analysis in Julia v1.11, which we're gonna have to fix. |
Is the issue that the current code relies on implementing methods on (Btw I really like Interfaces.jl which I use this in DynamicExpressions.) |
Surely if https://github.com/JuliaCollections/AbstractTrees.jl works without a type hierarchy, Graphs.jl could also work? I don't see a fundamental reason one would work and not the other |
There's no fundamental reason to prevent it, indeed. But as with most other big changes people want from Graphs, it would require time and manpower that we don't have at the moment. And it would probably be breaking.
I hadn't even thought of that but it could indeed be a problem for
I do too, and I use it in GraphsInterfaceChecker.jl to formalize the |
Probably the easiest thing to do is define a separate module Graphs
eltype(x) = Base.eltype(x)
end Then you can overload as normal directly on |
In https://juliagraphs.org/Graphs.jl/stable/ecosystem/interface/ it specifies that we need to subtype to
AbstractGraph
to use these methods. I am wondering if there could be a trait-based version instead? Since Julia doesn't allow multiple inheritance it means we wouldn't be able to depend on both our own abstract type (which includes non-graph objects) as well as interface with Graphs.jlcc @robdancer. x-ref SymbolicML/DynamicExpressions.jl#98 (comment)
The text was updated successfully, but these errors were encountered: