#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:550 nthiery]:
> No it's not a global name.
> {{{
> This caveat is no different from that of name clashes in hierarchy
> of classes involving multiple inheritance.
> }}}
That is incorrect, there are never name clashes in multiple inheritance.
You can name your class anything you want, the only thing that counts is
the the actual class as Python code. You can even have two classes with
the same name in the same module and inherit from both. Absolutely no
problem:
{{{
sage: class A(object):
....: x = 1
....:
sage: a = A
sage: class A(object):
....: x = 2
....:
sage: class Multiple(A, a):
....: pass
....:
sage: Multiple.__mro__
(__main__.Multiple, __main__.A, __main__.A, object)
sage: Multiple.__mro__[1].x
2
sage: Multiple.__mro__[2].x
1
}}}
This is one of the fundamental promises of OO in general and the object
system in Python in particular: The '''name of a type does not matter'''.
Breaking that basic premise is a neat idea but not something that is fit
to serve as the underpinning of a scientific Python library.
I know you are talking about method names, but there you cannot have
accidental clashes either. 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. Accidental name clashes can only happen when there is no syntax to
tie the related classes (or axioms, or "things", ...) together, and this
is precisely what I'm worried about on this ticket.
> 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?
--
Ticket URL: <http://trac.sagemath.org/ticket/10963#comment:553>
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.
