GROMACS

Currently, the Selection class contains quite a few methods like

  rvec x(int i) const;
  real mass(int i) const;
  ...

I think it would be better to make the interface less flat to better describe the structure of the data, i.e., that a selection is made of a set of positions, which then have some properties. There are also some selection-level properties. This division would make the class more intuitive to use.

There are several possible solutions that I can imagine. All have a common feature: a lightweight wrapper class that looks conceptually like this:

class Selection::Position
{
    public:
        rvec x() const;
        real mass() const;
        ...

    private:
        Selection *sel_;
        int  index;
};

This wrapper class provides methods to access all properties of one single position, and just reads them from the underlying data structures in Selection. I can see two basic alternatives on how this can be used:

1. Provide methods
   

     int positionCount() const;
     Position position(int i) const;
   

   
   in Selection.
2. Provide a container or a look-a-like container:
   

     const PositionList &positions() const;
   

   
   This approach further can be divided based on what PositionList is:
   1. PositionList is std::vector<Position>. A similar alternative is to redefined Position such that it contains all the necessary information, but then it is necessary to duplicate some information from the internal gmx_ana_pos_t structure.
   2. PositionList is a custom non-STL container.
   3. PositionList is a custom container that tries to behave as std::vector<Position> where possible, but only stores the Selection pointer and the index in iterators, not with every element.

I'd like some comments on which alternative would be the best before I start implementing one of them. I personally prefer either 1 for its simplicity or then 2.3, but I wouldn't want to start implementing 2.3 only to find it rejected in review due to its complexity. On the other hand, if 2.3 is the way to go, I wouldn't want to first implement 1 and convert call sites more than once. I'll try provide more thoughts on the advantages and disadvantages of these options later, but let this serve as a conversation starter.