Opened 3 years ago

Last modified 3 months ago

## #29234 new enhancement

# Inheritance Structure: Tensor Fields -> Vec. Bdl. Sections

Reported by: | Michael Jung | Owned by: | |
---|---|---|---|

Priority: | major | Milestone: | sage-9.8 |

Component: | geometry | Keywords: | tensor-bundles, vector-bundles |

Cc: | Eric Gourgoulhon, Travis Scrimshaw | 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 (14)

### comment:2 Changed 3 years 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 3 years 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 3 years ago by

Milestone: | sage-9.1 → 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 2 years 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 Changed 2 years ago by

Replying to gh-mjungmath:

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 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 2 years 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 Changed 2 years 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 2 years ago by

Milestone: | sage-9.2 → sage-9.3 |
---|

### comment:10 Changed 22 months ago by

Milestone: | sage-9.3 → sage-9.4 |
---|

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

### comment:11 Changed 17 months ago by

Milestone: | sage-9.4 → sage-9.5 |
---|

### comment:12 Changed 12 months ago by

Milestone: | sage-9.5 → sage-9.6 |
---|

### comment:13 Changed 8 months ago by

Milestone: | sage-9.6 → sage-9.7 |
---|

### comment:14 Changed 3 months ago by

Milestone: | sage-9.7 → sage-9.8 |
---|

**Note:**See TracTickets for help on using tickets.

It would be a shame when some documentations of tensor fields will be erased due to this task. Any suggestions how to keep them?