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 implementComponent
.-
Composite
's methods fromComponent
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
andDiscreteNetCollection
. - Both could be
Transformable
(NetCollection
already is) -
SmoothNetCollection
could have a methodsample(sampling) -> DiscreteNetCollection
that just samples each child. -
DiscreteNetCollection
could have a methodto_blender_object()
that could even automatically mirror theDiscreteNetCollection
tree structure in blender collections.
- Split it into
-
HalfedgeCollection
with methodsto_blender_object()
,validate()
and maybe others -
GeometricObjectCollection
that contains geometric objects likeSubspace
,Quadric
,Sphere
. It could have membersambient_dimension
,to_smooth_net() -> SmoothNetCollection
andat_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 (likeDiscreteNet
orHalfedge
objects) would also need ato_blender_object
method. They don't. We would have to add method aliases forto_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.