#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, | 8045aa4a4b7ada735b3eb6055382f9b341a39f1e
#10193, #12895, #14516, #14722, | Stopgaps:
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506 |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Hi Nicholas,
Great work writing up the documentation. It's very accessibly written and
very friendly in tone. I see you're not done yet. One (in my view major)
point I don't see addressed yet:
'''base_category''':
While you argue why the code is ''written'' like a (spanning) tree of the
acyclic digraph, I don't see it argued why it needs to be reflected in
further data structures. In particular, I don't see why "base_category" is
necessary at all. Surely we need to know what the super categories are,
but I don't see why one needs to be preferred.
In fact, as soon as classes get implemented in their own module rather
than as a nested class, there isn't a natural tree structure anyway.
Apart from that some minor comments about coding conventions and class
use.
'''old style classes''': If you type `class ElementMethods:`, you create a
nested class that is an old-style class in python 2. Since you're
basically only interested in `ElementMethods.__dict__` anyway, this is
perhaps not such an issue. Old-style classes have some semantic
differences. I don't know if they have any significant performance
differences, and probably they don't have any performance differences that
matter for your very limited application.
'''nested classes''': are a little strange in python. The syntax suggests
the class would become a kind of closure with the enveloping class as
scope closed over. That is ''not'' the case, however, which is probably
good for your purposes. It's one reason why nested classes aren't very
popular, however: they add an extra indentation level and they aren't any
different from a separate class, even though the lexical context might
suggest differently. So I'd lean towards ''not'' nesting axiom classes. At
the cost of one attribute assignment `Finite=FiniteGroups` (or something
like that), you're being spared extra indentation on ''many'' lines. It
probably also makes the code easier to read for people who don't usually
use a code-folding editor.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:375>
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.
