On Saturday, September 14, 2013 8:54:30 AM UTC+1, Simon King wrote:
> The classical example are matrix spaces. Generally, matrix spaces are
> modules, and thus its elements should inherit from ModuleElement (I
> think they do!). But if the matrix space happens to be quadratic, then
> it is a ring.
And since the shape of matrices is immutable, it is the classic example for
inheritance that I mentioned.
> Do we really want to create two separate implementation for matrix spaces
> and their elements, one for the quadratic and one for the non-quadratic
> case?
>
We do already have special implementations for structures that arise for
square matrices only, in particular matrix groups and group algebras comes
to mind.
Also, we should of course NOT have separate implementations of square vs.
rectangular matrix. The square matrices should inherit from rectangular
matrices and add the methods they need. If you can't be bothered with
actually typing class SquareMatrix(RectangularMatrix, RingElement) then you
can use the same dynamic metaclass trickery that is used in the category
approach.
Of course is in principle possible to do anything that can be done with
inheritance with composition instead. From a user perspective, this is
basically equivalent since you don't need to know where a method comes from
if you want to call it. But for somebody trying to implement a ring
structure it makes a world of a difference. Everybody with a passing
knowledge of Python understands what it means to inherit from RingElement.
But if you move to composition then you need to know that you had to pass
some special argument in the constructor of the parent. So you need to do
something completely unintuitive, and in a separate class to boot. That is
what I meant by "inheritance is easier to understand".
It is true that composition reduces the combinatorial explosion when you
want classes with different combinations parents. So if you routinely use
all combinations of {square, rectangular} x {module, ring} then you are
better of with composition again as there is no clear inheritance
hierarchy. But that is definitely not the case here.
> Actually it *can* be a problem even in a Python class inheriting from
> two Cython classes. Namely, I once tried to create a class that inherited
> (if I recall correctly) from both from Map (or Morphism) and
> RingElement
Thats why I said that this is a potential problem in Cython. But since
RingElement inherits from ModuleElement and no other Cython classes are
around, this is not a problem here. You only must not inherit from
different Cython base classes (even if intermediate classes are in Python).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.
