Can we change ILink implementation to be non generic?

[rolyhudson]

Planning longer term use of Graph as an analytical element. (This question relates to #988)

It may very useful to use the ILink interface to construct relationships between Nodes of different types.

Currently the StartNode and EndNode properties are constrained to a single Type that implements INode

What are the benefits of constraining as currently implemented?

What about switching to a non-generic version like

public interface ILink : IBHoMObject, IAnalytical, IElement1D
    {
        /***************************************************/
        /**** Properties                                ****/
        /***************************************************/

        INode StartNode { get; set; }

        INode EndNode { get; set; }

        /***************************************************/
    }

Thoughts on this @IsakNaslundBh, @FraserGreenroyd, @al-fisher, @adecler ?

[FraserGreenroyd]

Can we move this to the discussions tab please and discuss there 😄

[IsakNaslundBh]

The reason for having them defined with generics is so that each discipline can have their objects pointing to the appropriate type of node. For example the Bar class in structures needs to have a start and end node of type BH.oM.Structure.Elements.Node to function properly across adapters etc. If we were to make the ILink interface into a non-generic as above, it would mean that the Bar class would need to have its properties changed from a structural node to an INode, and that would mean you could assign an Environments node to it, or any other node for that matter. This would for reasons stated above not work.

Had different ideas on how to handle this without the generics when the interfaces were first added, but all of them would include extension methods etc, and would not give that much benefit as an addition and to help ensure that the oMs stay aligned.

Basically, it comes down to the usage on the actual classes themselves, that need to have the restriction, and not from what we would absolutely like on the interface. If c# would allow you to define the interface as you have above, whilst still restricting the bar class to Structure nodes, that would be ideal, but unfortunately not possible.

[rolyhudson]

@IsakNaslundBh thanks for the explanation - very clear. Basically the generic definition is protecting users? Helping them know what implementing type to pass in and therefore avoiding downstream problems if for example an environmental Node is used to define a bar.

Makes me think / realise the analytical graph should in fact be designed to be more abstract. Constraining it to work with INode + ILink in the first case assumes it is spatial - which may not always be the case.

[IsakNaslundBh]

Basically the generic definition is protecting users? Helping them know what implementing type to pass in and therefore avoiding downstream problems if for example an environmental Node is used to define a bar.

Not only to protect the users, but also developers and to be able to make classes that in themselves are guarantied to work. If I ask for the nodes from a Bar, I am sure that I get a Structural node back, no need for endless type checking and casting each time you retrieve one of the properties.

Basically, the interfaces was constructed to match the classes we knew we wanted to put them on, rather than the other way around, and that, unfortunately, meant having to rely on generics. :)

[al-fisher]

Makes me think / realise the analytical graph should in fact be designed to be more abstract. Constraining it to work with INode + ILink in the first case assumes it is spatial - which may not always be the case.

Yes - agreed on this. We will need (at some point) a generalised version of a graph which can store the relations between non-spatial. I have imagined two versions of this too - following our conversations @rolyhudson.
One version referencing/pointing to instances of the objects.
One version which stores simply the hashes.
I think we might need/want both. The latter similar to the way our old push to Mongo worked as @adecler mentioned, we changed to storing the objects as made sense for Mongo queries, then and right now. But ultimately now we will want choices of how we store our relationships - depending on how we use them downstream

[IsakNaslundBh]

With a risk of overusing empty interfaces...

We could add an empty interface called ILink that has required extension methods for getting out the start node and end node, similar to the IElement pattern we have in place. Could then implement a default implementation for it for the ILink<TNode> in analytical enigne.

Not 100% sure this is a good idea or not though, or if it is just building unnecessary complexity...

[IsakNaslundBh]

Makes me think / realise the analytical graph should in fact be designed to be more abstract. Constraining it to work with INode + ILink in the first case assumes it is spatial - which may not always be the case.

Had another think about this @rolyhudson and think we could fix this by:

• Remove the Position property from the base INode interface
• Add a new interface, IGeometricalNode : INode that do store a position

Then all the geometrical nodes (all current INodes) can instead implement IGeometricalNode, and can change geometrical methods in Analytical_Engine that right now works on ILink<T> where T : INode to ILink<T> where T : IGeometricalNode. Then you can be free roly to work with empty node interfaces basically, if that would help?

[rolyhudson]

Good suggestion @IsakNaslundBh and probably necessary for general graph operations to have a non-spatial and a spatial node.

Initially I thought the INode and ILink may have been convenient interfaces for the general graph case. Now I think it maybe simpler and better to separate the concerns and back up the abstraction level a bit for the general graph.

What would be important is converts from a network of INode and ILink to the general graph (where node duplication is prevented). That would provide a means of applying graph tools to structural and mep networks.

What I have been thinking recently (picking up on notes and conversations with @al-fisher @adecler ) the way forward is developing a graph of List<Edge> and List<Vertex> where the Edge is just a pair of Guids or Hashes of the linked objects.

(The names Edge and Vertex would follow convention for naming of graph components but Edge is already used to signify another concept of edge -so probably something else should be used.)

Graph algorithms could be developed to function on a graph of List<Edge> and List<Vertex>. When a graph includes objects that are spatial we can allow spatially driven versions of methods like shortest paths (where link lengths rather than link counts are used to compute costs). I imagine we could also add Fragments to the links to provide further input (like weights).

[IsakNaslundBh]

ILink would still be constrained to represent spatial links and I think we will need a non-spatial way of representing an ILink also.

That is my point though. If we changed having two different Nodes, ILink on the class side would only require INode. What I ment with

geometrical methods in Analytical_Engine that right now works on ILink where T : INode to ILink where T : IGeometricalNode

is that we might have some methods that only works on geometrical ILinks (" ILink<IGeometricalNode> ") but the class itself does not need to be constrained to be only geometrical.

Then that means that you can do stuff such as getting out the geometry etc for any ILink that is geometrical in the Analytical_Engine, but still, on just the level of the class, there is 0 requirement for it being geometrical.

[IsakNaslundBh]

Had another thought about this, and found a big reason why this might not be possible...

We currently have the ILink implementing the IElement1D interface, and probably want to keep it that way for the hierarchy of interface to work as intended and to be able to have default methods available in the Analytical_Engine

[rolyhudson]

Good point so it should remain a spatial link defined by spatial nodes.