#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 | ece5c973b179319616ff99c3f2ddfd2b6dfcdfd4
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:560 vbraun]:
> And what is the alternative in the category framework to creating a
subcategory of both C and D? In Python it is clear that multiple
inheritance is not the answer to everything, and you can e.g. use object
composition to combine classes as an alternative. But here I don't see a
way to avoid a name conflict, hence in the above situations the names
truly do clash and the poor sap who wants to combine C and D for the first
time is thoroughly screwed.
Do you have a single concrete use case?
I don't see one. And if ever we have one, categories don't prevent
composition more than usual classes; it will be time then to extend
the framework to nicely support whatever form of composition we will
design based on concrete experience with concrete use cases.
I am tired of speaking in the vague about hypothetical issues when
there are so many concrete problems that needs urgently to be worked
on.
> Except my sentiment in comment:380 was more along the lines of "if Guido
van Rossum were dead then he'd be turning in his grave right now" ;-)
I know. I have a strong opinion that the more Sage knows about
mathematics, and uses this knowledge, the better code structure we
will have. This has motivated all the work I put into the category
infrastructure.
> Anyways, coming back to constructive suggestions: Lets just get rid
> of the subclass syntax. Really, that has no business on this ticket
> which is supposed to be the initial implementation of axioms. First
> you need to have a solid implementation of the axioms and relations,
> then you can think about beautifying the syntax. This just amounts
> to a lot of dedenting, inserting `_base_category_class_and_axiom` in
> the right places, and deleting some metaclass magic. Since "manual"
> construction of category-with-axioms is supposed to be always
> possible we also wouldn't have to publicize a programming interface
> that is going to be yanked away in the future. Once we are happy
> with the implementation we can think about providing a more concise
> syntax in a future ticket.
We have been using this nested class syntax for functorial
constructions since the initial implementation of categories in
2009. It has proven a very practical way to structure the code, we
never had a problem with it, and developers learned it all right. I
don't see why we should deviate from this syntax for axioms.
Now, if you mean that we should also get rid of the nested class
syntax for functorial constructions as well, then fine, fine. Go
ahead. Take over the maintenance and development of categories. I am
out of it.
> But IMHO we should focus more on the implementation first, e.g. find
> ways to not do a potentially-infinite recursive computation on
> startup etc.
This problem is fixed.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:561>
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/d/optout.
