Open CameronBieganek opened 9 months ago
@gdalle Any thoughts on this?
I think it makes development harder to have two unregistered repos, so I would put it on the back burner for now (not that development is really active either ^^). However I kinda like the idea for the medium term when things are more fleshed out
We did a lot of work on an abstract interface package for MCMC over here, and my experience from that was that it is useful, albeit contentious, to have an interface only package. I personally liked the setup but interfaces can be extremely "sticky" and hard to iterate on once they are in place. Ime I would make this an interface-only package and then just let it grow out.
You may already know some of this but I'll stick it in here since I am not nearly as familiar with the graphs ecosystem as you all. Some conclusions from AbstractMCMC:
AbstractGraph
, AbstractVertex
or AbstractNode
, AbstractEdge
, etc. Everything here is good and should be moved over, though this error should contain (a) the type that was called and (b) the method that was invoked.interfaceimplementation(x)
or something should give you specific instructions on how to implement each method, provide links to docs, a list of omitted interface methods, etc.edges
, neighbors
, getindex
, setindex
, etc. should be almost all of what anyone should need to implement (I think you already have this for the most part but I just wanted to state it).Just some opinions, in no particular order and not particularly well formed.
It seems like it would be convenient to have a package that defines only the
AbstractGraph
interface without providing any implementations, similar to how Tables.jl and DataAPI.jl work. That way packages that implement new graph types only need to depend on the interface package.On the other hand, does the new package extensions feature reduce the need for separate interface packages? I haven't played around with package extensions yet, so I don't know the answer to that question.