Changes between Version 3 and Version 4 of Ticket #29581, comment 53
- Timestamp:
- 08/25/21 07:41:00 (12 months ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #29581, comment 53
v3 v4 1 1 Thank 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. 2 2 3 One way to achieve this could be to allow `_representative` to refer to a method. But I suppose this is rather spurious for the user?3 One way to achieve this could be to allow the attribute `_representative` in `DeRhamCohomologyClass` to refer to a method. But I suppose this is rather spurious for the user? 4 4 5 5 Alternatively, 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.
