#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 | 977a940beba7ed96722a24e36cd81595336350ef
Dependencies: #11224, #8327, | Stopgaps:
#10193, #12895, #14516, #14722, |
#13589, #14471, #15069, #15094, |
#11688, #13394, #15150, #15506, |
#15757, #15759 |
-------------------------------------+-------------------------------------
Comment (by nthiery):
Replying to [comment:553 vbraun]:
> I know you are talking about method names,
Precisely.
> but there you cannot have accidental clashes either.
Oh yes we can. The analogue of our situation is as follow.
Take two unrelated classes `C` and `D` that both *define* a method
`x.foo()` but with different semantic. Take a subclass `E` of `C` and
`D`, and `e` an instance of `E`. Then `e` is an instance of `C`. So
wherever the method `e.foo()` comes from, it should implement the
semantic specified by `C`. But also that specified by `D`.
> In the '''very first line''' of the class definition the programmer
> must specify the base classes and their order, so which method comes
> first in the MRO only reflects the programmer's choice.
Whatever choice the programmer makes in the above situation, the
outcome is semantically wrong.
Besides, any hope to have a non-trivial control on the MRO for
hierarchies of dozens of classes is illusory. It's way to non-local.
> > Especially since, if in doubt about the semantic of the ``Finite``
> > axiom, one can just use introspection:
>
> But that is precisely what I said is not good enough. First of all we
must strive for readable code where relationships between classes (or
axioms) are clear from looking at it. The best code is code that doesn't
need to be documented. What if a user is trying to fix a bug that prevents
Sage from starting up?
The axioms involved when starting Sage are: Finite, Infinite,
Associative, Unital, and a couple similar ones. I don't think the
reader needs much explanations about their meaning.
Now, yes, not all relationships can be read statically from the code,
since a lot is deduced dynamically. However:
(1) We are modeling natural mathematical facts, so the reader can use
that information to understand the code.
(2) That's the whole point: like in a math paper we write the
important lemmas; not all possible combinations thereof.
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:555>
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.
