Suggestion: PathFactory to create instances of Path

[Tapanito]

Hello,

I ran into a situation where I need to extend the default Path implementation with some additional features. Currently, this is impossible as all search algorithms just call the Path constructor. I am using my own implementations of of Node and Edge interfaces, however I use some of the provided search algorithms. However, the default Path implementation, when retrieving nodes or edges, returns the interface rather than my concrete implementation, thus I have to do the casting myself. This in itself is not a big problem, a further complication is that, there is no way to extend the Path class. For example, PriorityQueue requires it's elements to implement the Comparable interface, which Path does not implement. Furthermore, I would like to extend the Path class with some further functionality needed for the search algorithms I'm working on. I can create my own Path class, however this would mean that I would have to re-implement the search algorithms that I use from your library to return my implementation of Path.

I would like to propose a PathFactory, which functions in the same way as the EdgeFactory or the NodeFactory. Rather than each algorithm initializing their own instances of Path, they would defer this responsibility to the PathFactory.
This will require extracting a Path interface, implementing a concrete default Path class, implementing a DefaultPathFactory, and updating the search algorithms to use the new PathFactory.

If you see the value in this change, I am more than happy to implement this, and open a pull request.

[hichbra]

Hi,

Yes of course, these changes look interesting, if you are ready to do the implementation, we have no objection.
But be careful, the change of Path may requires modifications in many algorithms and tests. Since these changes will be for the next release, please work in the dev branch. Good luck

[Tapanito]

I've started working on this feature, I've noticed that Path is only used inside gs-algo package. Is there a reason why it's kept in the gs-core package, and not gs-algo?

[hichbra]

Because it's a generic feature, same goes for some classes used in gs-ui-* .