OpenWaterAnalytics
Rewrite the API functions to be id and not index based
With the upcoming ability of changing the network, or building a new network from scratch, objects are no longer intrinsically linked to an index.
It therefore makes more sense to make the API functions such as ENgetnodevalue and ENgetlinkvalue take the object id as input instead of the object index.
agree. not sure what this means for backwards compatibility, but makes sense design-wise to leave indexing as an internal implementation detail.
Wouldn't this slow down setting and retrieving data as the index would need to be found each function call?
It would yes, although i'm not sure how expensive the lookup table lookups are. We could also argue that, in order to set and retrieve values we have to lookup the index anyhow. In addition, the extra overhead of calling two functions, e.g. ENgetnodeindex and ENgetnodevalue, especially in a dynamic typed language such as Python or Matlab, to get a single value may prove to be of bigger impact on the performance.
The scenarios in which index based functions win is for retrieving time series data, or for making iterative changes to the network characteristics without changing the layout.
In the end it's a choice between convenience and performance. ID based is much more fool-proof, especially with the new ability to change network layout. Index based offers a slight edge in performance. Maybe there is a middle ground, where we have both ENgetnodevalue(char *id) and ENgetnodevalueforindex(int index) functions?
makes sense to maintain backwards compatibility... however if the network is mutable, then the indices really aren't meaningful. tracking elements by ID is a move toward better object orientation. we could also expose blind pointers to the Snode/Slink objects and pass them into API functions which would be a very solid step toward OO, but there's a good question here about how much to extend 2.x toward OO vs putting effort into 3.x
This is already implemented in epanet-dev's Network class (although it hasn't made it into its API since the latter is still a mirror of the 2.x API). I guess what I'm suggesting (like a broken record) is that it's time to close out 2.x and move on to a true C++/OOP 3.0.
