sub-peepers and their methods: abstract classes?

Question

sub-peepers and their methods: abstract classes?

brisvag opened this issue 4 years ago · comments

I think that with out current idea of sub-Peepers, there would be quite a bit of code duplication, or weird inheritance networks.

What do you think of having a few abstract classes with topic-specific methods, and then our peepers could inherit from any combination of those, while adding whatever connection is needed?

alisterburt · Answer 1 · Thu Nov 19 2020 23:07:09 GMT+0800 (China Standard Time)

Yeah this sounds good, did you have any specific examples in mind?

…

On Thu, 19 Nov 2020 at 15:51, Lorenzo Gaifas ***@***.***> wrote: I think that with out current idea of sub-Peepers, there would be quite a bit of code duplication, or weird inheritance networks. What do you think of having a few abstract classes with topic-specific methods, and then our peepers could inherit from any combination of those, while adding whatever connection is needed? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#24>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXYBYHX2HZDVILGDMOCWS3SQUWHFANCNFSM4T3P6V2Q> .

Lorenzo Gaifas · Answer 2 · Sun Nov 22 2020 22:51:33 GMT+0800 (China Standard Time)

For example, particle-related operations would be in one of these abstract classes. Then, a Peeper used for just particles can use them, as well as a RefinementPeeper that would also inherit from an image-related abstract class. this woudl allow the 2 peeper to reuse code, while having (for example) different constructor for easier creation.

Lorenzo Gaifas · Answer 3 · Wed Nov 25 2020 17:27:23 GMT+0800 (China Standard Time)

I'm not so sure anymore about this. The more I play around with the idea, and the more I get convinced that everything should be available in Peeper, so that if any data is added, no matter how you started you will be able to handle it.

We should probably set up a bit better the io_ module and have an all-encompassing read function (probably with modes) so that creating a peeper is seamless. this can probably be accessed by the peeper with an add_data() method, so that i can be used on init as well as later on.

As for everything else (displaying, analysis...), we should probably put everything in a generic peeper.

alisterburt · Answer 4 · Wed Nov 25 2020 18:48:39 GMT+0800 (China Standard Time)

Gotcha, I think this can work and indeed may simplify things for eventual users! How about setting it up so that in its constructor the `Peeper` takes only a list of `DataCrate`s We could then implement any custom construction by factory methods such as `from_relion_refinement_directory`, `from_relion_refinement_star_file` etc. This gets verbose quickly, subpeepers could then just be `Peeper`s which have a few modes for reading the necessary files etc, e.g. RefinementPeeper knows during construction the things it could be looking for and constructs from the correct `from_*` method?

…

On Wed, 25 Nov 2020 at 10:27, Lorenzo Gaifas ***@***.***> wrote: I'm not so sure anymore about this. The more I play around with the idea, and the more I get convinced that everything should be available in Peeper, so that if any data is added, no matter how you started you will be able to handle it. We should probably set up a bit better the io_ module and have an all-encompassing read function (probably with modes) so that creating a peeper is seamless. this can probably be accessed by the peeper with an add_data() method, so that i can be used on init as well as later on. As for everything else (displaying, analysis...), we should probably put everything in a generic peeper. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXYBYBZSR7XKOAXDJ5QSEDSRTEYXANCNFSM4T3P6V2Q> .

Lorenzo Gaifas · Answer 5 · Wed Nov 25 2020 18:58:10 GMT+0800 (China Standard Time)

I agree until the last point: I think it's strange and unintuitive that the object you're holding only differs in construction methods.
I would go with something like numpy's np.array(), which "alsways" spitsout a ndarray and it's only job is to guess from the input how to construct it.

alisterburt · Answer 6 · Wed Nov 25 2020 19:00:33 GMT+0800 (China Standard Time)

hmm okay, I'm having a hard time seeing how we get everything to match up when we try to infer everything from the data itself but it's a nice goal!

…

On Wed, 25 Nov 2020 at 11:58, Lorenzo Gaifas ***@***.***> wrote: I agree until the last point: I think it's strange and unintuitive that the object you're holding only differs in construction methods. I would go with something like numpy's np.array(), which "alsways" spitsout a ndarray and it's only job is to guess from the input how to construct it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXYBYBTPHODVCK7CN5DEALSRTPNDANCNFSM4T3P6V2Q> .

Lorenzo Gaifas · Answer 7 · Wed Mar 03 2021 18:26:31 GMT+0800 (China Standard Time)

Obsolete/closed by #68 .