A more general approach to collections of objects (like NetCollection)

Motivation

It could be useful to have more collection-type objects like NetCollection, where collections of objects can be treated the same as individual objects in some ways (they can be transformed and visualized, have an ambient dimension,...).

There's a name for this

This type of design is called the Composite pattern. It consists of:

• An interface Component that specifies what both individual objects and collections of those objects should be able to do.
• Classes Leaf1(Component), Leaf2(Component),...
• A class Composite(Component) that maintains a list of children that also implement Component.
  • Composite's methods from Component will be implemented as just calling the respective method of all its children and possibly doing something with the result.

Some use cases I can imagine

• Use the pattern to formalize NetCollection with an interface
  • Split it into SmoothNetCollection and DiscreteNetCollection.
  • Both could be Transformable (NetCollection already is)
  • SmoothNetCollection could have a method sample(sampling) -> DiscreteNetCollection that just samples each child.
  • DiscreteNetCollection could have a method to_blender_object() that could even automatically mirror the DiscreteNetCollection tree structure in blender collections.
• HalfedgeCollection with methods to_blender_object(), validate() and maybe others
• GeometricObjectCollection that contains geometric objects like Subspace, Quadric, Sphere. It could have members ambient_dimension, to_smooth_net() -> SmoothNetCollection and at_infinity().
• Once the Cominatorics interface exists (#480), collections of combinatorial objects could also implement it, or at least a subset of its specification.

Challenges

• Our API is not really designed with this in mind. For a collection to have a to_blender_object method, all children (like DiscreteNet or Halfedge objects) would also need a to_blender_object method. They don't. We would have to add method aliases for to_smooth_net, to_blender_object etc.
• There's the usual issue that the "same" method of a different type would take different arguments. For example, to_smooth_net for a subspace takes different keyword arguments than for a quadric. But perhaps some common core functionality can still be realized.