Changes between Version 2 and Version 3 of Ticket #29581, comment 53


Ignore:
Timestamp:
Aug 25, 2021, 7:40:22 AM (13 months ago)
Author:
Michael Jung
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #29581, comment 53

    v2 v3  
    11Thank you Travis for your comments. My original idea was to inherit from `DeRhamCohomologyClass`. Because both classes have the `representative` method in common, which is crucial to perform operations such as additions and cup-products. My "dream" would be that an element of `CharacteristicCohomologyClassRing` can be seen as member of `DeRhamCohomologyRing`, and whenever `representative` is invoked (even after coercions), you can still choose a connection.
    22
    3 Alternatively, we can modify `DeRhamCohomologyClass` in such a way that we can give it a name and allow to leave the `_representative` attribute empty. Similar to scalar fields whose expressions are not set yet. Afterwards, the representative can be set dynamically, and we can make the instance immutable if desired.
     3One way to achieve this could be to allow `_representative` to refer to a method. But I suppose this is rather spurious for the user?
    44
    5 Last idea: we allow `_representative` to refer to a method. But I suppose this is rather spurious for the user?
     5Alternatively, if we drop my "dream" and still allow coercion: we can modify `DeRhamCohomologyClass` in such a way that we can give it a name and allow to leave the `_representative` attribute empty. Similar to scalar fields whose expressions are not set yet. Afterwards, the representative can be set dynamically, and we can make the instance immutable if desired.
     6
     7What would you prefer Travis? Eric, do you have an opinion, too?