#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_info
Priority: major | Milestone: sage-6.2
Component: categories | Resolution:
Keywords: days54 | Merged in:
Authors: Nicolas M. Thiéry | Reviewers: Simon King, Frédéric
Report Upstream: N/A | Chapoton
Branch: | Work issues:
public/ticket/10963-doc- | Commit:
distributive | c718f218fbc726bf3cf7f4c3f20638c9b0c7eea7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by vbraun):
Replying to [comment:502 nthiery]:
> This ambiguity is already resolved by the fact that you are
> implementing a category with axiom (which you know from the
> inheritance from Finite.Category).
Not quite, the author might just want to implement an unrelated category-
with-axioms. Or store an existing category in an attribute. I just think
we should err on the side of being more explicit rather than less here,
because if you accidentally trigger this mechanism you'll have a really
bad time.
> If you have concrete examples to test, I am interested! The only
> constraints that you have to respect is that the
> {{{extra_super_categories}}} methods should return strict super
> classes.
Well, as the most extreme case, they could just return nothing.
> Anyway you want, except using the same name as for the axiom if you
> still want to support {{{.Finite()}}} without {{{classget}}} magic
Ah, sorry, I also want this:
{{{
class Test1(Category):
Infinite_or_any_other_name = subcategory_with_axioms(axioms.Infinite)
# parsed by the metaclass
FiniteCommutative = subcategory_with_axioms(axioms.Finite,
axioms.Commutative)
}}}
which is in the url I linked but I haven't copied here.
You can, of course, use the same name. But you don't have to, and you have
to put it into code if you do.
> Sorry for the ambiguity: I am speaking of the printing of the category
> with axiom classes.
The order of axioms (which is also the print order) is specified in the
`axioms` object. So nothing changes there.
> I am still reluctant with that business. When we implement
> Groups.Finite, it's about the finite groups category. And I believe
> the magic, if any, should reside in the nested class and not in
> Groups. For otherwise, we should do the same for consistency for
> functorial constructions. And if we want later to add yet another type
> of construction, beyond axioms and functorial constructions, the
> metaclass of Groups will have to handle all of them, instead of having
> each nested class just handle its own specifics. So much for
> separation of concerns.
Fair enough, but you can inherit from metaclasses as usual. So the
standard OO mechanism for dealing with this concern apply. Even though I
don't recommend having too many meta classes.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:503>
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.
