the runner wants to be able to get a loader generically, so it relies on any implementor of LoaderInterface to get one
the StandardLoaderWrapper class implements LoaderInterface, so the runner uses StandardLoaderWrapper to get a loader
the StandardLoaderWrapper class wraps the StandardTomoLoader class, so then the latter can be used by the runner
the StandardTomoLoader class can be very slightly modified (adding three property-getters, detector_x, detector_y, angles_total) to implement LoaderInterface, to avoid the extra layer of StandardLoaderWrapper
remove the make_data_source() method on the LoaderIntarface protocol (which then means that StanardTomoLoader now would implement LoaderInterface)
then, make the loader factory function make_loader() return an instance of StandardTomoLoader instead of StandardLoaderWrapper
are simply using StandardTomoLoader.global_shape, and that the make_data_source() method is implemented simply by creating a StandardTomoLoader instance.
What this means is that:
if LoaderInterface only required the three property getters detector_x, detector_y, angles_total
then StandardTomoLoader could easily be changed to implement LoaderInterface
and the runner would be able to get access to an implementor of both LoaderInterface and DataSetSource from having an instance of StandardTomoLoader
Lastly, the make_loader() factory function could then simply create instances that implement both:
LoaderInterface
DataSetSource
and the runner would be able to get a data source without needing to use an intermediate "loader wrapper class" to generate a data source.
I think this could possibly make the "way" that the runner gets access to a data source simpler, and easier to understand, by getting rid of a layer in the generation of data source.
TL;DR
LoaderInterfaceto get oneStandardLoaderWrapperclass implementsLoaderInterface, so the runner usesStandardLoaderWrapperto get a loaderStandardLoaderWrapperclass wraps theStandardTomoLoaderclass, so then the latter can be used by the runnerStandardTomoLoaderclass can be very slightly modified (adding three property-getters,detector_x,detector_y,angles_total) to implementLoaderInterface, to avoid the extra layer ofStandardLoaderWrappermake_data_source()method on theLoaderIntarfaceprotocol (which then means thatStanardTomoLoadernow would implementLoaderInterface)make_loader()return an instance ofStandardTomoLoaderinstead ofStandardLoaderWrapperDetails
The
Pipelineobject represents the loader and methods in the pipeline. In particular, for the loader, it requires anything that implements theLoaderInterfaceprotocol: https://github.com/DiamondLightSource/httomo/blob/f6bb8aca8a4fb10cce5dd55c94dff2d0f1d77325/httomo/runner/pipeline.py#L12-L14When the UI layer creates a
Pipelineobject, it creates an implementor ofLoaderInterfaceby using themake_loader()function (which could be viewed as a factory function for implementors ofLoaderInterface): https://github.com/DiamondLightSource/httomo/blob/f6bb8aca8a4fb10cce5dd55c94dff2d0f1d77325/httomo/ui_layer.py#L143-L159The task runner then uses the
make_data_source()method defined on theLoaderInterfaceprotocol to generate an implementor ofDataSetSource: https://github.com/DiamondLightSource/httomo/blob/f6bb8aca8a4fb10cce5dd55c94dff2d0f1d77325/httomo/runner/task_runner.py#L226Now, the way that
StandardLoaderWrapperimplementsLoaderInterfaceis mostly by using theStandardTomoLoader.global_shapegetter: https://github.com/DiamondLightSource/httomo/blob/f6bb8aca8a4fb10cce5dd55c94dff2d0f1d77325/httomo/loaders/standard_tomo_loader.py#L394-L421Note that the three property getters:
detector_xdetector_yangles_totalare simply using
StandardTomoLoader.global_shape, and that themake_data_source()method is implemented simply by creating aStandardTomoLoaderinstance.What this means is that:
LoaderInterfaceonly required the three property gettersdetector_x,detector_y,angles_totalStandardTomoLoadercould easily be changed to implementLoaderInterfaceLoaderInterfaceandDataSetSourcefrom having an instance ofStandardTomoLoaderLastly, the
make_loader()factory function could then simply create instances that implement both:LoaderInterfaceDataSetSourceand the runner would be able to get a data source without needing to use an intermediate "loader wrapper class" to generate a data source.
I think this could possibly make the "way" that the runner gets access to a data source simpler, and easier to understand, by getting rid of a layer in the generation of data source.