#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 vbraun):
You are parsing the "Finite" class name, I don't care if it is explicit
using string tools/regexes or implicit looking for classes whose names
match certain strings. The usual way is to provide a programmatic
interface that sets up stuff in code. You should avoid using strings for
program flow, and most certainly not use them for foundational material. I
wouldn't care so much if we were talking about some implementation details
in the combinat project, but you expect us to go around and teach others
to use this. That better have a really good reason for the current
interface. **Simple** would be something that follows usual patterns (even
if its a few characters more). I don't see anything simple here, I see a
bunch of trickery that is extremely hard to understand by looking at the
code.
And you don't need operations on axioms? I see a lot of weird stuff in
this ticket where you use strings to do operations that would be much
clearer if you had some object to represent the axiom. E.g.:
{{{
sage: FiniteFields()._without_axiom("Commutative")
}}}
vs.
{{{
sage: FiniteFields().without(Commutative())
sage: FiniteFields() - Commutative()
}}}
Its an absolute no-brainer in Python to model **everything** with objects.
Which file implements the commutativity axiom? If I have an object then I
can tell immediately. Where is the documentation for the `Commutative`
axiom? Lets keep it simple and explicit, yes. Shorter but non-discoverable
is most certainly not simpler. And explicit is better than implicit, as
always.
Also, I don't agree with atomicity in setting
`_base_category_class_and_axiom` buys us anything. Its private by
convention, so it is the job of the setter to make changes atomically if
necessary (though thats hardly an issue in Python). But in multi-threaded
Java, say, this would be a bad data structure as well. We all know the old
joke, whats the only data structure in Cobol? A 2000-character EBCDIC
string...
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:389>
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.
