#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 | 7ab3103368e46d33f37e135a9eb09a1e16a029a7
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Back from vacations ...
Replying to [comment:541 vbraun]:
> Replying to [comment:539 nthiery]:
> > (1) I believe that, when implementing a category with axiom Cs().A(),
> > enforcing that the nested class be Cs.A is a feature (it's a
> > simple rule, it's consistent both with OO practice
>
> No it is not OO practice, in fact it is a smack in the face of normal OO
practice. This is and remains my main objection to the current syntax:
Cs.A and Ds.A are supposed to be totally independent **unless** you choose
to tie them together. First of all OO is about separation and
encapsulation, and you violate that basic principle. You keep ignoring me
and reiterate that its "just OO" when it is clearly not. Can you please
address this issue?
It's such a pain to have this kind of discussions on trac since every
time you try to be synthetic you face the risk of a misunderstanding
and it takes hours to clear that misunderstanding ...
Ok, let's go for it. I did not mean "categories are just
OO". Otherwise we would not need categories in the first
place. Instead, categories build on OO, and try to reuse the same
paradigms whenever possible. I did not mean either to argue about
nested classes. Just about their names.
So, let me restate this point in detail: not all features of categories
pass to subcategories. Hence, even if Ds() a subcategory of Cs(), the
class Ds is not a subclass of Cs. So the hierarchy of categories is
not directly a hierarchy of classes. Yet, some features *do* pass to
subcategories; this include *covariant* functorial construction and
axioms. Then it's natural to follow the usual OO paradigm where, when
something in the hierarchy attaches a semantic to a name (e.g. by
declaring a method with that name), the subthings in the hierarchy can
implement that semantic by reusing the same name.
> You keep ignoring me
Hmm, really?
The design behind this ticket is certainly non trivial, and you have
been raising natural questions about it. Answering those questions was
an helpful guide for me to write down the 1500+ lines of documentation
to expose the design decisions and the rationale behind. Now, I'd
appreciate if you would acknowledge the efforts I put in writing this
documentation, and use it as a basis for a constructive discussion.
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:543>
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.
