#14711: Weak references in the coercion graph
-------------------------------------+-------------------------------------
Reporter: jpflori | Owner: davidloeffler
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-6.1
Component: number fields | Resolution:
Keywords: memleak, number | Merged in:
field, QuadraticField | Reviewers:
Authors: Simon King | Work issues:
Report Upstream: N/A | Commit:
Branch: | 37bf59eac24eda1ece89aff7dde4a1db5d0cbb5c
u/SimonKing/ticket/14711 | Stopgaps:
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:164 SimonKing]:
> Replying to [comment:158 mmezzarobba]:
> > It looks like there has already been plenty of discussion about this
branch, and stupid merge conflicts with `develop` accumulate while it is
waiting for review. Could someone please clarify which parts of the
changes still need review?
>
> Actually I don't know. Nils?
I didn't look at code with the purpose of review, but to figure out if our
solution was conceptually the right one.
In the current coercion framework, something along the lines of this patch
is necessary to avoid lifetime problems as mentioned in the ticket, so I
guess someone can just go ahead and carefully read if the code does what
it supposed to do and doesn't add to the confusion the coercion framework
is prone to. Ideally, the patch might fix some of the horrible name
choices in the coercion framework.
The end result of our investigations was: The coercion framework is
purposely messy. It wasn't clear at the time what model would work well,
so the ball was kicked further down the road: The main tool is
`_coerce_map_from_` (note the underscores!) which is to be implemented by
the author of a parent class and programmatically generates coercion maps.
It is responsible for ensuring generating results that are consistent with
the fact that path-connectedness is closed under composition.
In the light of that: The coercion system is not particularly designed to
have any lifetime implications. Structures should keep related other
structures alive by themselves (base rings etc.). So weakening lifetime
implications as happens here should be OK.
--
Ticket URL: <http://trac.sagemath.org/ticket/14711#comment:165>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
