Opened 20 months ago
Last modified 3 months ago
#29234 new enhancement
Inheritance Structure: Tensor Fields -> Vec. Bdl. Sections
Reported by: | gh-DeRhamSource | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-9.5 |
Component: | geometry | Keywords: | tensor-bundles, vector-bundles |
Cc: | egourgoulhon, tscrim | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
This ticket is created to establish a concise and efficient inheritance structure between sections of vector bundles and tensor fields in order to avoid or reduce code redundancies.
In this ticket, we restrict the modification to tensor fields only. The issue "vectorframes -> local frames" is devoted to another ticket (opening soon).
Change History (11)
comment:1 follow-up: ↓ 2 Changed 20 months ago by
comment:2 in reply to: ↑ 1 Changed 20 months ago by
Replying to gh-DeRhamSource:
It would be a shame when some documentations of tensor fields will be erased due to this task. Any suggestions how to keep them?
This is certainly something to discuss (and more generally all the topic of this ticket) during your visit in Meudon in two weeks.
comment:3 Changed 20 months ago by
The documentation is not lost. It will just appear as links in the compiled doc (which is a bit of loss for the ?
form). You can also just append it with + BaseClass.__doc__
I think, but I am not sure I would do this.
comment:4 Changed 18 months ago by
- Milestone changed from sage-9.1 to sage-9.2
Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.
comment:5 follow-up: ↓ 6 Changed 15 months ago by
I guess, a first way to start would be to let TensorField
inherit from Section
since the most common code snipptes are hidden there. Then we can try to use a pattern like
def overloaded_method(self, *args, **kwargs): r""" Keep documentation and docstring """ return super().overloaded_method(args, kwargs)
to keep the documentation.
Alternatively one could think about another documentation page functioning as a compendium for these kind of things.
I'd prefer the former option because this is easier for users who are not involved in the development process to follow the changes, meaning things are kept as known for them.
comment:6 in reply to: ↑ 5 Changed 15 months ago by
Replying to gh-mjungmath:
I guess, a first way to start would be to let
TensorField
inherit fromSection
since the most common code snipptes are hidden there. Then we can try to use a pattern likedef overloaded_method(self, *args, **kwargs): r""" Keep documentation and docstring """ return super().overloaded_method(args, kwargs)to keep the documentation.
This is code duplication and should be avoided IMHO.
Why not pasting the current doctests in TensorField
to the EXAMPLES
section of the method implemented at the section level? In this way, the end user will still discover these examples with the ?
key.
comment:7 follow-up: ↓ 8 Changed 15 months ago by
As part of this refactorization, one could also extract a class representing general (pre)sheaves. This should actually not be too difficult as both implementations of sections as well as tensorfields mostly talk about the restriction of the section/tensor field to an open subset, i.e. exactly the sheaf-property.
comment:8 in reply to: ↑ 7 Changed 15 months ago by
Replying to gh-tobiasdiez:
As part of this refactorization, one could also extract a class representing general (pre)sheaves. This should actually not be too difficult as both implementations of sections as well as tensorfields mostly talk about the restriction of the section/tensor field to an open subset, i.e. exactly the sheaf-property.
Actually, this is an amazing idea. This is also beneficial in the sense that we can put all preexisting examples regarding tensor fields and sections in there since they represent the most prominent examples for sheafs on manifolds. By the way, scalar fields also define sheafs and should be covered here, too.
comment:9 Changed 14 months ago by
- Milestone changed from sage-9.2 to sage-9.3
comment:10 Changed 8 months ago by
- Milestone changed from sage-9.3 to sage-9.4
Setting new milestone based on a cursory review of ticket status, priority, and last modification date.
comment:11 Changed 3 months ago by
- Milestone changed from sage-9.4 to sage-9.5
It would be a shame when some documentations of tensor fields will be erased due to this task. Any suggestions how to keep them?