Refactor parts of Xobjects, propose introduction of inheritance

[szymonlopaciuk]

Description

This PR aims introduces:

• A standardisation of the API of Xobjects, lots of docstrings
• Inheritance of structs. This PR changes the layout of a Struct: see the top of struct.py for details.
• A new XoClass type, which can be used to implement dynamically dispatched methods for structs on both the Python and C side. See the top of xoclass.py for an example usage and the implementation.
• Generation of _get_size and _inspect_args for arrays in the metaclass depending on whether the array is static or not.
• Removal of unused code.

Caveats:

• This PR, as is, should be working, but I did not have the time yet to test it extensively on the different contexts, etc. Performance testing is also still pending.
• XoClass is currently hardcoded to be dynamic: as a proof of concept it should be enough though, as apart from the extra 64 bits in size it should not affect performance is a huge way.

Checklist

Mandatory:

• [ ] I have added tests to cover my changes
• [ ] All the tests are passing, including my new ones
• [ ] I described my changes in this PR description

Optional:

• [ ] The code I wrote follows good style practices (see PEP 8 and PEP 20).
• [ ] I have updated the docs in relation to my changes, if applicable
• [ ] I have tested also GPU contexts

[rdemaria]

Thanks for this big PR. Here are some quick comments from a superficial reading:

• The standardisation of the API of Xobjects is very good!
• Inheritance of structs it is an interesting idea, but causes Structs not using this feature to have larger size (e.g. doubling all drifts , without benefits and the derived class have slower access to members (if I have understood well). Still probably worth experimenting; therefore, I would keep the old Struct as is and add another say IStruct that implements this feature without interfering with Struct.
• XoClass I think I understand the idea, but I feel that using inheritance to express similar methods, mixes two concepts: data structure and methods. Why is it different from (I)Struct?
• Array specialization is very good!
• Removal of unused code: it looks like some useful code has been removed. It relates to pre-init post-init hook, which could be implemented differently, but it is needed. The methods for arrays types are needed as well, I think.

[szymonlopaciuk]

Thanks for your comments! I think in the immediate future I will focus on separating the-things-we-want-now and the-things-to-be-experimented-on-in-the-future. Definitely it's also necessary for me to test the performance of this implementation vs. the old one. Sadly I've not managed to do that yet, but I will try before I come back as well. That said, some comments/answers to your comments:

Inheritance of structs it is an interesting idea, but causes Structs not using this feature to have larger size (e.g. doubling all drifts , without benefits and the derived class have slower access to members (if I have understood well). Still probably worth experimenting; therefore, I would keep the old Struct as is and add another say IStruct that implements this feature without interfering with Struct.

The slower access to members should only affects the first dynamic field, the rest of the implementation is basically the same. As for doubling drifts: this is not a problem for the "Struct" of this PR, as they remain static sized. If implemented with the XoClass in the current implementation of the Line, then they would increase in size, though it's potentially not a disaster: if we were to put the elements derived from the XoClass, we can drop the usage of UnionRef, so the grand memory total is not necessarily changing so much (esp. if a hypothetical static version existed), but the implementation of the tracker could be simplified greatly. (The big question is whether the latter is worth the effort though...)

XoClass I think I understand the idea, but I feel that using inheritance to express similar methods, mixes two concepts: data structure and methods. Why is it different from (I)Struct?

Just to separate the code and the concept of date structure and the methods. And mostly to make it easier to remove if we don't want it.

Removal of unused code: it looks like some useful code has been removed. It relates to pre-init post-init hook, which could be implemented differently, but it is needed. The methods for arrays types are needed as well, I think.

My approach was basically to run the tests without and see that nothing breaks (Xtrack), but it's not a problem to readd them.

[giadarol]

Stale