#11935: Make parent/element classes independent of base rings
------------------------------------------------------------------+---------
Reporter: SimonKing |
Owner:
Type: enhancement |
Status: needs_work
Priority: major |
Milestone: sage-5.10
Component: categories |
Resolution:
Keywords: parent class, element class, category | Work
issues:
Report Upstream: N/A |
Reviewers: Nicolas Thiery, Travis Scrimshaw
Authors: Simon King | Merged
in:
Dependencies: #9138, #11900, #11943, #12875, #12876, #12877 |
Stopgaps:
------------------------------------------------------------------+---------
Comment (by nthiery):
Hi Simon!
Thanks for putting the rational of this patch to trial!
Let me call "category class" the element/parent/... classes of
categories. Here is my rationale for having them *not* inherit from
anything (the fact that they did in a couple exceptional cases has
always been in my mind a temporary hack to ease the transition to
categories).
- From a OO point of view, we want to keep category classes as close
possible from the model of a hierarchy of abstract classes providing
generic code.
Homset is a concrete class (in the sense that it provides data
structure, ...); so having a category class inherit from it deviates
from this model.
- This makes the model simpler to explain: C.element_class contains
code provided by C and its upper categories. Nothing else. The
hierarchy of classes for parents / elements is perfectly parallel to
that of categories.
- This allows to give a clean description of the mro of a parent (or
an element). First a sequence of concrete classes, related by single
inheritance, that roughly speaking describe the data structure and
basic methods of the object:
E.g. CombinatorialFreeModule -> Parent -> CategoryObject -> SageObject
Then, all the category classes that give the generic algorithm. All
mutiple inheritance is concentrated in this part of the mro.
This leaves full freedom for organizing it to avoid conflicts (like
in the upcoming C3 patch) or to do further optimizations. If a
category class inherit from, say, Homset, then Homset will appear in
the middle of category classes in the mro, and this is more likely
to create mro conflicts.
My theory is that we should always be able to avoid inheritance of
category classes upon anything else; and in fact that this should
actually point us to cleaner design. Now I'd be more than happy to
test this against concrete situations like #14279.
The logic in Hom is such that every homset is anyway constructed as an
instance of the concrete class Homset or some of its subclasses
(RingHomset, ...). Could you point me to the exact problem that arised
when you worked on it?
Cheers,
Nicolas
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11935#comment:100>
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
