#10963: More functorial constructions
-------------------------------------+-------------------------------------
Reporter: nthiery | Owner: stumpc5
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.1
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 | Commit:
Dependencies: #11224, #8327, | eb7b486c6fecac296052f980788e15e2ad1b59e4
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by vbraun):
Replying to [comment:423 nthiery]:
> The point is "within the desired feature set". For the idiom:
> {{{
> class C:
> class Anyname(MyAxiom.Category):
> ...
> }}}
> (1) You need to scan through the entries of ``C`` to decide whether
> ``C`` implements ``MyAxiom``, right?
Yes, of course.
I also think that the code on this ticket suffers from a lot of abuse of
lazy imports. They are a useful tool, but they don't absolve you from
thinking about import order of modules. If you do, then you'll run into
precisely the kind of hard-to-debug errors that we found. In particular,
lazy imports that you have to resolve on startup are IMHO a sure sign of
code smell.
This is yet another reason why I want to divorce axioms from categories.
Axioms clearly ought to be lower than categories in the import priority,
and moving them into separate files forces you to treat them as such.
> I think it's an important feature of the current design that you
> can use a category and some of its axioms while completely
> ignoring the others.
Agreed.
> Either you define MyAxiom in a location of its own. But then you
> loose some code locality (the code for the axiom is not tied to
> the category defining it, which I find important).
But axioms are **not** tied to particular categories. They can be added to
categories, but there is no need to have a unique "most basic category"
for the axiom. And you yourself complained that its annoying to move the
axiom code up in the category hierarchy occasionally.
> Or, as I
> mentioned before, you take the risk of having non trivial
> refactoring in case you generalize the axiom to a super category
> later.
No, you just move the import from your old category to your new category.
> Altogether the current design just follows by analogy standard OO
> practice: when a class C defines a method or attribute named ``a``,
> this fixes the semantic of ``a`` for all subclasses.
You are deliberately omitting the other half of the story: If you have two
unrelated classes `C` and `D` then `C.a` and `D.a` are unrelated in
Python. And you are breaking that.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:426>
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.
