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

[DeRhamSource]

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).

CC: @egourgoulhon @tscrim

Component: geometry

Keywords: tensor-bundles, vector-bundles

Issue created by migration from https://trac.sagemath.org/ticket/29234

[DeRhamSource]

comment:1

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

[egourgoulhon]

comment:2

Replying to @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.

[tscrim]

comment:3

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.

[mkoeppe]

comment:4

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.

[mjungmath]

comment:5

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.

[egourgoulhon]

comment:6

Replying to @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 like

def 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.

[tobiasdiez]

comment:7

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.

[mjungmath]

comment:8

Replying to @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.

[mkoeppe]

comment:10

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