Any intention to support different underlying data structure for meshes?

[drelatgithub]

I am looking for a data structure where one can perform dynamic local mesh operations. (Specifically, I'm interested in 2d surface meshes, so examples of local mesh operations include edge flipping, edge collapsing, edge splitting, etc.) Meanwhile, I would also like to implement an efficient algorithm on mesh neighboring element traversal (for example, to find all triangles around a given vertex). Currently, I find that the surface meshes provided by this package keep track of a list of triangles (I might be missing something here), but then it would be very expensive to do neighbor element traversal or local mesh modifications. On the other hand, a half-edge based surface mesh (used by CGAL, for example) can be much more efficient in local mesh operations (which, of course, does not come without a price: it would use more memory space, and will use more indirections to find vertices of a face).

So my questions are:
Assuming various underlying mesh data structures representing the same mesh can be implemented, do they conceptually belong to this package? Or should they be implemented as a different package?
If it does conceptually belong to this package, would there be any plans to support it? Meanwhile, if needed, I can definitely help with the details of implementation.

[SimonDanisch]

The mesh type is defined in it's most abstract form as AbstractArray{<: Polytope}... So any object that can be treated as a AbstractArray{Polytope} is supported ;)

[SimonDanisch]

the Mesh object, is just the standard implementation, but you dont need to use it... But, you could also easily create the Mesh object from an array of polytopes, that has a different connection information stored etc ;)

[drelatgithub]

I see. Thanks for the explanation!