Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

using process() and uniformity of class interfaces #701

Open
KrisThielemans opened this issue Jun 4, 2020 · 0 comments
Open

using process() and uniformity of class interfaces #701

KrisThielemans opened this issue Jun 4, 2020 · 0 comments

Comments

@KrisThielemans
Copy link
Member

It makes it far easier to the user if most classes act the same. The set_input();process();get_output() terminology was suggested by @ckolbPTB as a generic way of doing things (for sirf.STIR to be completed with set_up(), and is indeed documented that way https://github.com/SyneRBI/SIRF/blob/master/doc/UserGuide.md#general-structure-of-the-classes-. It's also reminiscent to the ITK pipelining idea, so would make our live easier when we wrap ITK.

I have no clear sight on how consistent we are with this (a consequence of not having a class hierarchy), but I did notice that neither sirf.STIR.Reconstructor nor sirf.STIR.AcquisitionModel have it. sirf.STIR.ImageDataProcessor does. Registration does. Resampling has it but is being discussed at #681.

Other classes use forward/backward (and direct/adjoint in Python). This works for CIL operators.

I still think it will pay-off to be consistent. Additional methods can be provided with more intuitive names.

One way to make this more obvious is to have a few base classes that guarantee a particular interface.

I'd like us to think and discuss what the appropriate style that fits most/all things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant