Associated data in a general way? After #665

[zerothi]

          Do you think there can be a way to treat associated data in a general way?

E.g. imagine in Geometry you keep an _associated_data dictionary pointing to objects that are associated to the geometry. For example it could contain an array of forces wrapped in some custom class CartesianVector. You could define some Geometry.apply_ufunc method that first applies the method on the geometry and then on the associated data.

In some sense Geometry has already three associated objects: the coordinates, Atoms and Lattice. I guess you can't apply the ufunc independently on each of them because there is some interplay in most ufuncs.

But still for example for the tile function, you could wrap the coordinates in some CellCoordinates class and then in geometry just do:

def tile(geometry, ...):
      xyz = geometry.xyz.tile(geometry.lattice, ...)
      lattice = geometry.lattice.tile(...)
      atoms = geometry.lattice.tile(...)
      return geometry.__class__(xyz, atoms, lattice)

So in essence Geometry is just a wrapper that instructs its members to apply the ufunc on themselves. Instead of defining the method you could just define the order on which to apply the ufunc and if there are dependencies:

sisl.Geometry.associated_data = ["xyz", "lattice", "atoms"]

# For the translate ufunc just apply the ufunc on everything, the order doesn't matter
# Perhaps this isn't even needed and the ufunc dispatcher could directly look for associated 
# data if there is no implementation for Geometry.
register_ufunc_wrapper(sisl.Geometry, "translate")

# Define how to apply the tile ufunc on Geometry
register_ufunc_wrapper(sisl.Geometry, "tile", [
    ("xyz", ["lattice"]),
    ... # Meaning the rest, without a required order.
])

It doesn't need to be exactly like that, but you get the idea. Maybe it is too abstract, but I just put my ideas here because you might come up with a version of it that is less crazy :)

Originally posted by @pfebrer in #665 (comment)