#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 vbraun):
Replying to [comment:555 nthiery]:
> > but there you cannot have accidental clashes either.
> 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` [...]
There is still no accidental clash. If you inherit from C and D then you
get exactly what you ask for. Your example is simply one where the
programmer actually does not want to inherit from both C and D. That is
fine, you also have the possibility to inherit only from one of them or
from neither. And you have that flexibility precisely because a) you have
a clear and concise syntax for specifying the parents and b) distinct
classes stay separate as long as you don't explictly tie them together.
> (1) We are modeling natural mathematical facts, so the reader can use
> that information to understand the code.
All of Sage is about modeling natural mathematical facts. Just because you
know Wedderburns theorem does not mean that everybody who ends up
implementing a ring knows it. And it certainly does not mean that somebody
who reads the code is going to expect that it is magically applied behind
the scenes. In fact, I claim that it is quite astonishing when you
encounter it for the first time. And if I may quote
http://en.wikipedia.org/wiki/Principle_of_least_astonishment: "If a
necessary feature has a high astonishment factor, it may be necessary to
redesign the feature."
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:556>
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.
