Quantcast

proposed interface change

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

proposed interface change

John Sichi
Administrator
Hey all,

One of the data modeling issues we faced way back when the JGraphT project started was how to represent all the diverse critters which populate the fascinating world of graph theory:  directed graphs, undirected graphs, weighted graphs, acyclic graphs, simple graphs, pseudographs, multigraphs, and on and on.  The decisions we made at that time were the following:

1) rule out some of the more exotic possibilities (e.g. hypergraphs)

2) use sub-interfaces to model some fundamental variations in graph structure (namely DirectedGraph, UndirectedGraph, and WeightedGraph)

3) treat the rest of the possibilities as constraints on the fundamental types, and provide a library of implementation classes to make it easy to apply and combine them

This has worked out fairly well, but over the years, we've seen flaws crop up, particularly around WeightedGraph (e.g. https://github.com/jgrapht/jgrapht/issues/116), as well as a lot of duplication of class implementations due to the split between DirectedGraph and UndirectedGraph

After various discussions in github, the project committers have collectively come up with a newer approach, and one of us (Dimitrios Michail) has put a big effort into belling the cat:

https://github.com/jgrapht/jgrapht/pull/366

This pull request deprecates decision #2 above.  Namely, we are proposing to phase out the UndirectedGraph, DirectedGraph, and WeightedGraph interfaces, unifying all of their methods into the existing Graph interface.  In place of compile-time type information, we're introducing the GraphType interface as run-time type information.  Hence, where before an algorithm might have required a DirectedGraph as input via method signature, it will now take a Graph, and then throw an exception if a graph of incorrect type is supplied as input.  This was already the approach for the less fundamental graph aspects (e.g. when an algorithm prohibited multigraphs as input), so now it is being applied uniformly.

We realize this may cause a bit of upgrade pain for existing apps which are written in terms of the sub-interfaces being deprecated.  But we believe it's a worthwhile tradeoff both in terms of library interface improvement and long-term library maintainability.  As always, we're planning to go through the usual deprecation process to make the transition as smooth as possible for apps and dependent libraries.  But before moving ahead with merging this pull request, we'd like to hear any feedback you might have on the new approach.

Thanks!


------------------------------------------------------------------------------
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
_______________________________________________
jgrapht-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jgrapht-users
Loading...