#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 | f1b6804c499bfdc9cd8a864f81f739d80783122d
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:545 vbraun]:
> That is one piece of OO. But it is not the "usual OO paradigm" unless
you also have encapsulation, that is, unrelated "things" being independent
(in particular, sub-things of independent things being independent).
Reusing (really: overriding) a name is supposed to replace one
implementation with another, but the original and the replacement are
still independent. Really, what you propose is more like a single flat
namespace where each axiom is a global name. And that is not OOP.
No it's not a global name. We have already discussed this, and here is
the answer taken from the documentation around line 394 of
category_with_axiom.py:
{{{
.. TOPIC:: Design note
Let us state again that, unlike what the existence of
``all_axioms`` might suggests, the definition of an axiom is local
to a category and its subcategories. In particular, two
independent categories ``Cs()`` and ``Ds()`` can very well define
axioms with the same name and different semantics. As long as the
two hierarchies of subcategories don't intersect, this is not a
problem. And if they do intersect naturally (that is if one is
likely to create a parent belonging to both categories), this
probably means that the categories ``Cs`` and ``Ds`` are about
related enough areas of mathematics that one should clear the
ambiguity by having either the same semantic or different names.
This caveat is no different from that of name clashes in hierarchy
of classes involving multiple inheritance.
}}}
> I certainly do acknowledge and appreciate your effort.
:-)
> But when it comes to reviewing I am supposed to be an advocate of
> other users, not of the author.
Certainly. Now, when it comes to be an advocate of users, one thing to
consider is who around here has accumulated the most experience using,
implementing, teaching, and helping others use and implement
categories and axioms.
> And I think there is too much implicit magic and not enough syntax
> to explicitly tie together the axiom implementations. Which will
> hurt other users/developers when they first encounter the category
> code. Just documenting that axioms are implicit magic is IMHO not
> good enough when you can just make their relationship explicit.
I know, we disagree here. IMHO this is explicit enough:
{{{
class Cs(Category):
...
class Finite(CategoryWithAxiom):
}}}
Especially since, if in doubt about the semantic of the ``Finite``
axiom, one can just use introspection:
{{{
sage: C = Cs()
sage: C.Finite?
}}}
Nicolas
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:550>
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.
