Only use the spaces concept in the TransformGraph

[clbarnes]

Resolves #3 ; raised again in #72 . Pinging @Tomaz-Vieira and @m-albert .

This does allow deleting a lot of code and works better as "one obvious way to do things". The downside is we lose a bit of sanity checking when chaining together coordinate systems.

[Tomaz-Vieira]

I really like where this is going =D

I think it makes it so much clearer (and less error-prone) that graph.add_transform now requires the spaces explicitly =)

The downside is we lose a bit of sanity checking when chaining together coordinate systems.

I was thinking about that too, and I wonder if there isn't a concept/type missing somewhere; Since the graph is aware of both transforms AND spaces, perhaps it could use something like a TransformPath[SpaceRef] to represent some path inside a graph, that could be aware of the origin and destination spaces. That's what you would get when querying the graph via graph.get_sequence(...). This of course raises the question of whether TransformPath is just TransformSequence, but tracking the spaces 🤔

Also, should one be able to instantiate a TransformPath outside of the graph, or even populate the graph by passing in a TransformPath?

I don't have these ideas well-formed in my head; maybe you'll have some counter-points off the top of yours =)

[clbarnes]

Yes, I started going down that path as well; something like

class SpacedTransform[ArrayT, SpaceRef](Transform[ArrayT]):
    def __init__(self, t: Transform[ArrayT], source: SpaceRef, target: SpaceRef):
        self.t = t
        self.source = source
        self.target = target

Then use that as the argument for transform_graph.add_transform, and give it special behaviour in a TransformSequence and so on.

The problem is that a bunch of functions specifically look at the type of transform when doing things like simplification (decomposing Bijections and Sequences to see if they can be turned into affines), so composing a wrapper over the top adds indirection there.

[clbarnes]

I've settled on a Spaced[ArrayT, SpaceRef] class which holds but doesn't expose the interface of the inner transform. Consumers who want the transform should do my_spaced.transform. So users can use this for bookkeeping if they want, and it's what's taken by TransfromGraph.add_transform (and returned when iterating through edges); but the classes unconcerned by spaces don't have to know about it. There are still some convenience methods, like chaining Spaceds together to get a Spaced wrapping over a TransformSequence, with all the spaces correct.

https://github.com/clbarnes/transformnd/pull/79/changes#diff-fde58b12fc14dab4ff9798373ae67e15d01c3be3cb01183ed1435514c76b87b8